[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#779294: /usr/bin/python: /lib/i386-linux-gnu/libc.so.6: version `GLIBC_2.15' not found (required by /usr/bin/python)

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

Reply to: