On Fri, Feb 27, 2015 at 08:17:26PM +0100, Andreas Beckmann wrote: > >> Preparing to replace python2.7-minimal 2.7.3-6+deb7u2 (using .../python2.7-minimal_2.7.8-11_i386.deb) ... > >> Unpacking replacement python2.7-minimal ... […] > >> Preparing to replace debconf 1.5.49 (using .../debconf_1.5.55_all.deb) ... > >> /usr/bin/python: /lib/i386-linux-gnu/libc.so.6: version `GLIBC_2.15' not found (required by /usr/bin/python) > >> dpkg: warning: subprocess old pre-removal script returned error exit status 1 > >> dpkg: trying script from the new package instead ... > >> /usr/bin/python: /lib/i386-linux-gnu/libc.so.6: version `GLIBC_2.15' not found (required by /usr/bin/python) > >> dpkg: error processing /var/cache/apt/archives/debconf_1.5.55_all.deb (--unpack): > >> subprocess new pre-removal script returned error exit status 1 […] > >> This looks a bit like python was unpacked before the new glibc. > > > > debconf calls pycompile (and python). It looks like this kind of thing can > > happen with any binary which needs the new glibc, and in this case it hits python. The dpkg error is talking about the prerm script of debconf. Looking at it shows that it indeed calls python scripts (pyclean, py3clean) generated by dh_python2 and dh_python respectively. Now, the guaranties you have while prerm is running are not really great: Everything can be half-installed (in a new version), but was configured (in an old version) [see §6.5]. Not really a 'problem' as debconf has no dependency on python-minimal at all, so it can be in any state anyway. Looking at python-minimal (which contains the /usr/bin/python link) and then on python2.7-minimal (which contains the link target) looks better: python2.7-minimal pre-depends on glibc, which is a strong guaranty and given that the log contains the unpack of python2.7-minimal, it should also contain unpack+configure of glibc – if the version already installed isn't high enough. The python2.7-minimal version 2.7.9-1 currently in sid pre-depends >= 2.15 on amd64 and i386 (and a bunch of other archs - not on all!), so we should have seen glibc here and before someone is showing log to disprove me, I presume tagging 'sid' was a mistake. The python2.7-minimal version 2.7.8-11 currently in jessie and the one this log was talking about pre-depends >= 2.15 on amd64, but on i386 the pre-depends is a relaxed >= 2.3.6-6~. That is satisfiable by wheezys libc6 (currently at 2.13-38+deb7u8) easily (The same or similar again for other archs as well). I have my doubts this version contains 2.15 symbols through, but this is by definition not apts fault. The question is now how this pre-dependency came to be, but that is something python and glibc maintainers can work out. Slightly unrelated sidenote: python-minimal might be better of pre-depending on python2.7-minimal. I have my doubts it could actually happen in practice, but in theory I could freshly install python and upgrade debconf in the following order: unpack python-minimal (the pyclean script is installed) unpack debconf (prerm finds pyclean script and calls it) unpack python2.7-minimal (the python interpreter is installed) The second one will fail as pyclean can't be executed as the interpreter isn't installed. APT will avoid doing this in general, hence my doubt that this is a problem in practice, but it is technically allowed (as long as debconf has no python dependency). This probably get slight more real if python-minimal ever decides to link to (e.g.) python5 instead. Best regards David Kalnischkies
Attachment:
signature.asc
Description: Digital signature