On Sun, May 19, 2013 at 05:15:35PM +0200, David Kalnischkies wrote: > Hi, > > 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. > > In the case of debconf, we don't even have a dependency on python, > so its even more fine to choose this order for unpack.
I don't think that debconf is relevant there. The problem is that the new python needs a new libc6 package, and thus if it is unpacked before libc6, it doesn't work anymore. This means that every python script on the system will fail (being called from a maintainer script or not), until the dependency is satisfied again. > > I haven't had the time yet to debug why APT is choosing this route > (and as said, dpkg/status file would help), but while this might not be > ideal its not a bug in APT. I really thought if a package A depends on package B, B has to be unpacked before A is unpacked. Otherwise it means that for example if the package dash starts to depend on a new libc6 version, while it is unpacked before this new version, all maintainer scripts written in shell will fail. > 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? ;) ). > The problem there is that /usr/bin/python exists is not a dead symlink. Just that it fails to be executed. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
