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
