Hi Andreas, On Wed, 29 Jan 2014 23:48:46 +0100, Andreas Beckmann <a...@debian.org> wrote: > 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.
Indeed, I realised that based on the timestamps; I was just curious as to why piuparts itself cleaned things up in an apparently non-policy-compliant order. > > (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 ... That's what I've done: the subprocesses wait as long as rmmod is available and the module is loaded, so when kmod is removed or the chroot goes away the subprocess stops. At least piuparts doesn't complain any more, and the prerm still works in the usual case (where we really want to remove the modules). Regards, Stephen
signature.asc
Description: PGP signature
