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. 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.) [I don't know if even that is enough or if apt/dpkg give special treatment to packages tagged Essential:yes in this context.] 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 see the py3clean invocation is generated by dh_python3 so this is probably going to be much wider issue than just libglib2.0-dev... Just my two cents, -- Niko Tyni nt...@debian.org
