Migrating the insserv enabling stuff from insserv to sysv-rc

[Petter Reinholdtsen]

[Petter Reinholdtsen]
> 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
> properly.

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. :/

Happy hacking,
-- 
Petter Reinholdtsen