Hi Stephen, On 2014-01-29 23:08, Stephen Kitt wrote: >> >From the attached log (scroll to the bottom...): >> >> 0m19.1s DEBUG: Starting command: ['chroot', '/tmp/piupartss/tmpqN70Hj', >> 'apt-get', 'remove', 'kmod', 'libkmod2:amd64', 'oss-compat'] 59m19.1s >> ERROR: Terminating command due to excessive runtime 59m19.6s DUMP: >> >> >> ***** Command was terminated after exceeding runtime limit (3540 s) ***** >> 59m19.6s DEBUG: Command ok: ['chroot', '/tmp/piupartss/tmpqN70Hj', >> 'apt-get', 'remove', 'kmod', 'libkmod2:amd64', 'oss-compat'] 59m19.6s INFO:
> Why is kmod purged before oss-compat? oss-compat depends on kmod, so > according to policy section 7.2, kmod should be left at least unpacked as > long as oss-compat is in the "configured" state (so that postinst and prerm > can use kmod). There is no guarantee on purge ordering, and therefore piuparts tries the worst case for a packages: after all its dependencies. But purge is not your problem here, piuparts first runs remove and thereafter purge. It is the the apt-get remove command that does not return (therefore no output is shown in the log). And the remove order is computed by apt-get according to the dependencies. > (In any case there is a bug in oss-compat's prerm, I need to at least detach > the subshells that are started to remove the modules.) But they should terminate gracefully if the modules are not loaded or /sys is not mounted or whatever may fail ... piuparts won't like processes being left running after the removal of a package ... Andreas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org