Migrating the insserv enabling stuff from insserv to sysv-rc
pere at hungry.com
Sun Aug 2 08:27:15 UTC 2009
> This conflict break upgrades, and installation with dpkg -i when I
> install more packages (insserv, sysv-rc, sysvinit, sysvinit-utils
> and initscrits). I'm not quite sure if this conflict is required or
> not. :/ Removing it made upgrades and dpkg -i installation work
The conflict is there to make sure no-one upgrade to a newer sysv-rc
or insserv without also upgrading the other package. It should only
be a problem if insserv is enabled. Here are the two scenarios:
* Upgrading insserv to a newer version while keeping a version of
sysv-rc without the depend on a newer insserv, will make it
possible to remove sysv-rc without getting a warning about enabled
dependency based boot sequencing. This is ok, and we do not need
the conflict for this. Those removing sysv-rc will have to insert
a replacement doing dependency based boot sequencing and know what
they are doing.
* Upgrading sysv-rc to a newer version will also depend on a newer
version of insserv. There is no need for a conflict for this.
This make me believe the conflict in insserv on older sysv-rc versions
is not needed.
> One idea presented by Daniel Silverstone when I discussed this
> problem with him, was to move the insserv binary into the sysv-rc
> package. It would basicly get rid of the problem.
This did not work. When sysv-rc replaces the old insserv package,
dpkg try to remove the old insserv package and fail to do so because
insserv is still enabled. Next, I tried a empty transition package
for insserv to avoid having to remove the old insserv package, but
this make update-rc.d disappear during upgrade when initscripts try to
run its postinst, and thus is no good either.
I suspect we will be stuck with the update-rc.d-insserv script for
squeeze, as no other working alternative have presented itself. :/
More information about the initscripts-ng-devel