Bug 1086343 - Dependency problem among libpango, libglib-2 and gio-branding-openSUSE
Dependency problem among libpango, libglib-2 and gio-branding-openSUSE
Status: NEW
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Upgrade Problems
Current
x86-64 openSUSE Factory
: P5 - None : Normal (vote)
: ---
Assigned To: openSUSE GNOME
Jiri Srain
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-03-21 18:00 UTC by James Carter
Modified: 2018-05-18 17:54 UTC (History)
2 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
Packages before the dist-upgrade (137.26 KB, text/plain)
2018-03-21 18:00 UTC, James Carter
Details
Packages after the dist-upgrade + downgrading gio-branding-openSUSE (138.59 KB, text/plain)
2018-03-21 18:05 UTC, James Carter
Details

Note You need to log in before you can comment on or make changes to this bug.
Description James Carter 2018-03-21 18:00:29 UTC
Created attachment 764495 [details]
Packages before the dist-upgrade

I did a dist-upgrade to openSUSE-release-20180318-1.2.x86_64 
(Tumbleweed).  On just one of my machines, I got two similar errors:
/usr/bin/qemu-system-x86_64: symbol lookup error: 
    /usr/lib64/libpango-1.0.so.0: undefined symbol: g_log_structured_standard
Starting service mdm /usr/sbin/mdm: symbol lookup error: 
    /usr/lib64/libpango-1.0.so.0: undefined symbol: g_log_structured_standard
There were definitely other programs, such as vi, which were similarly
affected but not seen in this quick scan of syslog.  

/usr/lib64/libpango-1.0.so.0 -> /usr/lib64/libpango-1.0.so.0.4101.0
from package libpango-1_0-0-1.42.0-1.1.x86_64 , updated on all hosts.
I also still have libpango-1_0-0-1.40.6-1.1.x86_64.rpm .  
zypper install --oldpackage libpango-1_0-0-1.40.6-1.1 (no errors). 
But that was not the correct fix: on restarting display-manager I got:
Starting service mdm /usr/sbin/mdm: symbol lookup error: 
    /usr/lib64/libatk-1.0.so.0: undefined symbol: g_log_structured_standard

It looks like several libraries use this method that presumably 
produces a standard format for log messages.  So which library is 
supposed to provide it?  Per Google, it perhaps appeared in glib-2.55.2.  
glib2-2.56.0 is official for Tumbleweed, and other hosts have 
libglib-2_0-0-2.56.0-1.1, but the failing one has 
libglib-2_0-0-2.52.2-3.1.x86_64 .  Why wasn't it updated?  

zypper install libglib-2_0-0-2.56.0-1.1
    glib2-devel-2.52.2-3.1.x86_64 requires glib2 = 2.52.2 which cannot
    be provided.  
    Solution 1: downgrade of gio-branding-openSUSE-42.1-7.7.noarch to 
				gio-branding-openSUSE-42.1-3.1.noarch
    etc. (sorry, I should have, but didn't, copy the whole message
    verbatim.)

I chose solution 1.  About 15 packages were upgraded, and that one was
downgraded.  Now the failing services (mdm for display-manager and qemu
for libvirtd) could be started.  

I didn't do a lot of research on why that downgrade was possible and 
effective, but I'd guess that gio-branding-openSUSE-42.1-7.7.noarch
depends on something that depends on glib2-devel-2.52.2-3.1.x86_64 
(the old one), while gio-branding-openSUSE-42.1-3.1.noarch (the old one)
has a different dependency that can be satisfied in the context of
having libglib-2_0-0-2.56.0-1.1 (the new one).  

If libpango-1.0.so.0 and libatk-1.0.so.0 (and probably others) call 
g_log_structured_standard, shouldn't they depend on glib2 >= 2.55.2 
or whenever it was added to that library?  (It does depend on 
libglib-2.0.so.0 without the version.)  

If they did depend on glib2 >= 2.55.2 , given that the machine starts
out with gio-branding-openSUSE-42.1-3.1.noarch, I wonder which packages
would be upgraded: to gio-branding-openSUSE-42.1-7.7.noarch preventing
upgrading libpango and friends, or would the solver pick the solution 
that upgrades the most packages, i.e. libpango and friends plus 
libglib-2_0-0-2.56.0-1.1, and luckily being able to come up with a
solution while holding back only one package, 
gio-branding-openSUSE-42.1-3.1.noarch .  

I'm attaching a list of packages on the failing host from before the
dist-upgrade, and after both the dist-upgrade and downgrading to
gio-branding-openSUSE-42.1-3.1.noarch .
Comment 1 James Carter 2018-03-21 18:05:20 UTC
Created attachment 764496 [details]
Packages after the dist-upgrade + downgrading gio-branding-openSUSE
Comment 2 Dominique Leuenberger 2018-05-14 09:17:01 UTC
(In reply to James Carter from comment #0)
> Created attachment 764495 [details]
> Packages before the dist-upgrade
> 
> I did a dist-upgrade to openSUSE-release-20180318-1.2.x86_64 
> (Tumbleweed).

Did you *REALLY* do a dist-upgrade (aka zypper dup)? That should handle downgrades like this without trouble EXCEPT if you have any repo in place that is still offering the higher version in plus.

(the release counter was reset because the source package was changed from a two linked packages to one _multibuild package)
Comment 3 James Carter 2018-05-18 17:54:35 UTC
Your guess is very likely correct, that I have repo priorities set in such a way that a repo with a lower priority number (more preferred) had a back-version instance of libglib.  I wanted to prove this, but ended up in a tangle, so I'm just confirming without proof.  

Do you have a recommendation for my use case?  I have an enterprise mirror, and a procedure to update it overnight and make a report of what packages are going to be updated, with their changelogs, so I can head off conflicts, e.g. update the webserver first, rather than when the other hosts are trying to use it to get packages from the enterprise mirror.  

So is there a standard way to prefer the enterprise mirror when the package versions are identical, but to prefer the SuSE repo if a new version sneaks in after the enterprise mirror is updated, which has happened several times?  

In response to the libglib mess, I tried replacing the enterprise mirror with a Squid proxy with more than enough cache space to hold every installed package.  This method looks promising but has its own little issues...