[debhelper-devel] Bug#887629: libc6: bad upgrade path: libexpat1 unpacked and python3 called before libc6 unpacked

[Guillem Jover]

Control: reassign -1 python2.7-minimal,python3.6-minimal,debhelper
Control: retitle -1 python: Wants to be used like Essential:yes but does not follow its requirements
Control: affects -1 - libc6 libexpat1
Control: affects -1 + libglib2.0-dev

Hi!

On Sat, 2018-01-20 at 23:19:30 +0200, Niko Tyni wrote:
> On Sat, Jan 20, 2018 at 05:07:30PM +0100, Andreas Beckmann wrote:
> > For now, I'd suggest the dummy empty libglib2.0-dev.prerm, but if this
> > error starts to show up elsewhere (e.g. in a package where both old and
> > new prerm use python3), probably adding the Pre-Depends to libexpat1
> > would be the general solution.
> 
> FWIW, I have the feeling that having libexpat1 Pre-Depend:libc6 would
> be a wrong place to fix this longer-term, though it might be a viable
> workaround for now. I fear that this will pop up with zlib1g (another
> dependency of python3.5-minimal in stretch) next as soon as it gets built
> against a newer glibc version. And having special handling in libexpat1
> and zlib1g because they happen to be dependencies of python3.x-minimal
> seems wrong.

Yes.

> The core problem here is python3 usage in 'prerm upgrade'. Non-essential
> packages are not generally safe to use at that point. AFAICS, if
> python3.x-minimal is intended to be usable in 'prerm upgrade', it
> needs to follow the same rules as essential packages: "must supply
> all of their core functionality even when unconfigured" (policy 3.8).
> In practice I think that means it must Pre-Depend on all the libraries
> it links against, (so libexpat1 and zlib1g in addition to the current
> pre-dependency on libc.)

Exactly right. :) BTW this would require a discussion on debian-devel,
even though I guess it might not be controversial.

> [I don't know if even that is enough or if apt/dpkg give special treatment
> to packages tagged Essential:yes in this context.]

dpkg only takes Essential:yes into account on removal, when showing
its scary prompt; and when deconfiguring a package, to refuse the
action. AFAIR apt uses Essential:yes as things that need to
be installed (if they are not), for its own scary prompt, and to
prioritize its installation at the beginning of the transaction.

> Now, as we can't change python3 in stretch anymore, we can either push
> this down the chain in sid/buster and modify new libexpat1 and zlib1g to
> pre-depend on libc as a workaround, or we have to add fallback 'new-prerm
> failed-upgrade' handling to the packages whose 'prerm upgrade' in stretch
> is using python3.

I don't think this needs to be changed in stretch anyway? The new
dependencies on the newer libc are coming from sid/buster, so fixing
that should be enough, AFAICS (but I've not looked very hard :).

> I see the py3clean invocation is generated by dh_python3 so this is
> probably going to be much wider issue than just libglib2.0-dev...

I'm also assigning to debhelper, in case this needs mitigations there
too. Feel free to sort this out between yourselves, by reassigning,
cloning or whatever. ;)

Thanks,
Guillem