On Sun, May 19, 2013 at 9:10 PM, Matthias Klose <d...@debian.org> wrote: > Am 19.05.2013 17:15, schrieb David Kalnischkies: >> The dpkg/status file before the upgrade could be helpful for reproducing. >> You can (hopefully) find it in /var/backup/ >> >> Helpful config options (I case someone wants to try) >> -o dir::state::status=./dpkg/status >> -o debug::pkgdpkgpm=true # displays dpkg calls rather than executing them >> -o debug::pkgorderlist=true # first stage order choices >> -o debug::pkgpackagemanager=true # second (and final) stage order choices >> >> On Sun, May 19, 2013 at 3:50 PM, Aurelien Jarno <aurel...@aurel32.net> wrote: >>>> /usr/bin/python: /lib/i386-linux-gnu/i686/cmov/libc.so.6: version >>>> `GLIBC_2.15' not found (required by /usr/bin/python) >>>> /usr/bin/python: /lib/i386-linux-gnu/i686/cmov/libc.so.6: version >>>> `GLIBC_2.16' not found (required by /usr/bin/python) >>>> dpkg: warning: subprocess old pre-removal script returned error exit >>>> status 1 >> >> While APT usually avoids it, its actually fine to have dependencies not >> satisfied for half-installed packages and prerm scripts do only give you >> the guarantee that your dependencies will be at least half-installed. > > well, only seen on i386, and apparently libc6-i686 is installed. Now why > aren't > the new libc6 packages unpacked first? I would assume to see more reports for > this upgrade path.
Its caused by the remove of libescpr1 (src:epson-inkjet-printer-escpr) in Richards case, which ignoring the ubuntu-popcon spike has a 25.000 score, so not installed by everyone and even if you have it installed you might have upgraded your libc6 earlier (as the libescpr1 drop is just two days old) or APT chooses a different package to handle first [removes are done relatively early compared to other actions]. I guess there are other situations where you can reach this problem, but you need to be a bit "lucky". Describing exactly whats going on is not only offtopic, but also complicated, so lets just say that APT is choosing here a bad way of handling things, but while its not a good idea its a valid one. (people wanting to explore the misery can follow the word "DepRemove") >> This smells more like a bug in dh_python2 which adds this prerm code which >> assumes that pyclean can be executed even if it isn't configured (aka that >> it behaves like an essential application), but I am not in the mood for >> bug-ping-pong so just CC'ed python maintainers for now, so they can have a >> look and comment on it while we will see whats up with APT to decide on >> this route (did I mention that a dpkg/status file would help? ;) ). > > so for now, I'm adding the libc6 dependency as a pre-dependency in > python2.7-minimal, like perl-base is doing. While this should work to fix this exact bug, its still papering over the problem indicated by the bug: python isn't essential, so pre* scripts can't assume that python is working. Usually you are lucky enough that it works "by accident", but bugs like this one show that you can very well be in a system state which is allowed by policy but python isn't working. (assuming the chosen order is better, e.g. loops can trigger this) To really fix this you have to ensure that a) python always works even in half-installed state OR b) all packages using dh_python2 prerm snippets pre-depend on python OR c) cleaning is moved to post* scripts and "just" depend on python OR d) the dh_python2 prerm snippet works without a configured python by using shell/perl/$essential tools only. Same goes for python3 and dh_python3. I am CCing the debconf maintainers btw as their prerm script looks really strange with 3 different ways of cleaning up pyc and pyo files – one handwritten shell and two added by dh_python2 (one requiring python and a fallback in shell). Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
