Le mercredi, 17 octobre 2018, 11.59:09 h CEST Simon McVittie a écrit :
> I would like advice from the technical committee on
> <https://bugs.debian.org/896019>. I am not asking for anyone to be
> overruled.
Thanks for your bugreport, thanks also for specifying you're expecting the TC
to act under §6.1.5.
> In #896019 and #894763, it appears that some upgraded systems somehow
> still contain a copy of libglib-2.0.so.0.4200.0 (corresponding to
> GLib from jessie) in /lib/MULTIARCH. We don't know how this can have
> happened. There are suggestions that it might have been caused by
> filesystem corruption or installed by third-party software.
It's _very_ suspicious that it's the exact same version, on two different
architectures. I skimmed through piuparts logs and didn't note anything
special.
Just because I don't know enough piuparts, I tried installing libglib2.0
2.42.0-2 in a jessie chroot, upgraded it and `dpkg -i`ed the stretch version
on top; the *.4200.* file disappears indeed.
> When it does, ldconfig sees that the obsolete library
> has SONAME libglib-2.0.so.0, and creates a symlink
> /lib/MULTIARCH/libglib-2.0.so.0. This takes precedence over the
> newer version of libglib-2.0.so.0 that is correctly installed in
> /usr/lib/MULTIARCH, resulting in the new libgobject-2.0.so.0 failing
> to load, because it uses symbols that are only present in the new
> libglib-2.0.so.0.
>
> Possible resolutions include:
>
> * Do nothing; consider the systems with a leftover
> /lib/MULTIARCH/libglib-2.0.so.0.4200.0 to be an unsupported local
> misconfiguration (this is the status quo)
>
> * Move libglib-2.0.so.0 back to /lib/MULTIARCH permanently, at a
> long-term complexity cost
>
> * Take steps to delete /lib/MULTIARCH/libglib-2.0.so.0.* during upgrade,
> taking care to avoid deleting files that are really on
> /usr/lib/MULTIARCH in merged-/usr systems, at a significant complexity
> cost, with some risk of deleting necessary files if we get it wrong
>
> * Advocate merged /usr where this class of problem cannot happen :-)
>
> Do technical committee members (other than me) have any thoughts on this?
Under the current analysis, it seems that these spurious files:
* originate from Debian-provided binary packages (the timestamps match)
* haven't been removed for some yet-to-be-found reason (dpkg/apt corner-case?)
* have appeared on two different architectures (kinda-ruling out the third-
party software hypothesis)
(I'd be very curious to know what sequence of events lead to such files being
leftovers…)
With that in mind (and pretty much inline with what the TC offered as advice
in #865929) and although it probably doesn't respect the Debian Policy letter,
I'm of the current opinion that a variant of your third option above is the
best course of action: in the preinst of libglib2.0, forcibly remove the
offending files from /lib/MULTIARCH/ if these are not known from dpkg and
match known checksums. Given the amount of bugs you mentionned (a handful),
I'd start with a closed list of offendants, that you can always extend later.
Given that it'd be a later version of libglib2.0 cleaning up traces of earlier
versions of itself, I see no real concern with that approach.
If third party packages really unpack files in /lib instead of their private
directory, then pulling the Debian carpet under their feet feels only fair
game to me. And trying the automated removal of these in Debian unstable is a
pretty good way to find out if such hypothetical cases exist.
I hope it helps!
Cheers,
OdyXAttachment:
signature.asc
Description: This is a digitally signed message part.