Bug#708831: upgrade-reports: [sid->sid] left system barely unusable (manually fixed with dpkg --install)
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 <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 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
aurelien@aurel32.net http://www.aurel32.net
Reply to: