On Mon, 03 Dec 2018 at 19:57:39 -0800, Xilin Sun wrote: > my /lib/x86_64-linux-gnu/libglib-2.0.so.0 was a symlink to > /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.1 > my /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 was a symlink to > /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.5800.1
I wondered whether it was significant that GLib 2.48.0 was in jessie-backports, but your obsolete shared library looks like it came from 2.48.1, so it's probably coincidence. Please send the output of these to the bug address (some of them will give error messages, that's fine; please send those too): ls -il /lib/x86_64-linux-gnu/libglib-2.0.so.* ls -il /lib/x86_64-linux-gnu/libgobject-2.0.so.* dpkg-query -S /lib/x86_64-linux-gnu/libglib-2.0.so.* dpkg-query -S /lib/x86_64-linux-gnu/libgobject-2.0.so.* ls -il /usr/lib/x86_64-linux-gnu/libglib-2.0.so.* ls -il /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.* dpkg-query -S /usr/lib/x86_64-linux-gnu/libglib-2.0.so.* dpkg-query -S /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.* dpkg-query -S /lib/x86_64-linux-gnu/*.so.* > /dev/null dpkg-query -S /usr/lib/x86_64-linux-gnu/*.so.* > /dev/null Also please look in /var/log/apt for the upgrade history of your libglib2.0-0 package (as far back as you can), tell us what the sequence of versions was, and check whether the upgrade transactions involving libglib2.0-0 logged any warnings or unusual messages in term.log. What is the history of this machine? What version of Debian did you originally install, and when did you switch the apt sources to take packages from sid? (For instance the answer might be "installed wheezy, upgraded to jessie, switched from jessie to sid in late 2016".) > Now that GLib puts these files under /usr/lib/x86_64-linux-gnu/, my > /lib/x86_64-linux-gnu/libglib-2.0.so.* files from an old version of > glib should certainly have been deleted during the installation of the > new version, but somehow this didn't happen. I'm surprised that dpkg can get into a situation where that can happen. > I suppose one way to reproduce this bug is to install the system with > libglib2.0–0 around version 2.48 and then do an upgrade to the latest > version. I tried installing GLib 2.42 from jessie (as seen in the original bug report) and upgrading that, but my test VM doesn't have this bug afterwards. If it was that easy to reproduce, all Debian users with GLib installed (including its maintainers) would have experienced this bug at the time of the transition from GLib in /lib to GLib in /usr/lib, so there must be some other factor involved. It's also noticeable that the stale GLib versions are relatively old - probably not the most recently-installed. On Mon, 03 Dec 2018 at 20:10:02 -0800, Xilin Sun wrote: > By comparing the file lists of package libglib2.0-0 in stretch and > sid, I think the old copy of libglib in /lib/x86_64-linux was > introduced by the package itself, not 3rd party installers. The file lists don't really prove anything either way: all we know is that something installed an older copy of GLib to the same path that an old Debian package would have used. Do you use any third-party apt sources, or do you have any third-party software installed that runs as root? Thanks, smcv