Bug#708831: upgrade-reports: [sid->sid] left system barely unusable (manually fixed with dpkg --install)
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 <aurelien@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 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.
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? ;) ).
Best regards
David Kalnischkies
Reply to: