On Sat, 2012-06-30 at 23:45:46 +1000, Russell Coker wrote: > On Sat, 30 Jun 2012, Guillem Jover <[email protected]> wrote: > > I've to question some > > things here though which would seem wrong with the SE Linux > > infrastrucute or design (and not with dpkg itself). > > I think it's more of a problem in documentation. If the man pages fully > explained what was happening then you would choose the raw variants because > it's faster and simpler.
Yeah, in addition there's no man pages for the _raw variants either. > Also the code that's currently in dpkg might even be older than the > sensitivity range translation mechanism that's currently in use. Probably. > > I've just quickly checked policycoreutils and it does not seem to be > > sopping or restarting the daemon during upgrades, so I'm guessing this > > can only happen if the daemon dies for whatever reason or the user > > stops it explicitly. The latter would be user error, the former seems > > to imply that the design of the infrastructure is a bit flaky? > > It certainly restarts the daemon during an upgrade, and if it didn't then > that > would be a bug which would need to be fixed. > > # dpkg -i policycoreutils_2.1.10-9_amd64.deb > (Reading database ... 166749 files and directories currently installed.) > Preparing to replace policycoreutils 2.1.10-9 (using > policycoreutils_2.1.10-9_amd64.deb) ... > [ ok ] Stopping restorecond (via systemctl): restorecond.service. > [ ok ] Stopping mcstrans (via systemctl): mcstrans.service. > Unpacking replacement policycoreutils ... > Setting up policycoreutils (2.1.10-9) ... > [ ok ] Starting mcstrans (via systemctl): mcstrans.service. > [ ok ] Starting restorecond (via systemctl): restorecond.service. > Processing triggers for man-db ... Ah right, was looking in the wrong place, I just checked now the binary package and see that it's stopping and starting in the maintainer scripts, but I think that's wrong, because older dpkg will not be fixed and an upgrade from those might fail. This should be switched to only restart in the new package postinst script and never stopped on upgrade, so that there's no time window where the daemon is not running during a dpkg transaction. You might need to immediately start the daemon in the new package preinst on upgrade, from after it has been stopped in the old package prerm to guarantee smooth ugrades from old packages though. thanks, guillem -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
