[Petter Reinholdtsen] > This of course need to be done carefully, to make sure the systems > with insserv enabled, stay enabled.
I am still working on this, and have come up with a modified plan. I am not happy with leaving the /usr/sbin/update-rc.d-insserv script behind, but I am unable to figure out a way to avoid that while still keeping update-rc.d working during the upgrade/migration. For the next insserv upload, version 1.12.0-11: - Conflict with sysv-rc (<= 2.87dsf-2), to make sure it is not possible to upgrade insserv without upgrading sysv-rc too. - Drop the depend on sysv-rc to avoid a dependency loop. - Also drop the dependencies on initscripts and sysvinit-utils previously used to make sure scripts supporting insserv enabled boot was used, and let sysv-rc handle this. - Drop all code in postinst++ to enable insserv, including update-bootsystem-insserv and update-bootsystem-insserv.8. - Do not touch the divert of /usr/sbin/update-rc.d, and keep /usr/sbin/update-rc.d-insserv to avoid a dangling symlink during upgrade. - Keep the file /var/lib/insserv/using-insserv to indicate that dependency based boot sequencing is enabled. For the next sysv-rc upload, version 2.87dsf-3: - Move the still active code in update-bootsystem-insserv from insserv to the sysv-rc postinst. - Rewrite update-rc.d to include the code in update-rc.d-insserv and use it when /var/lib/insserv/using-insserv exist. This mean we can drop the divert previously done by insserv postinst using update-bootsystem-insserv. - Rewrite the postinst++ to remove the insserv divert of /usr/sbin/update-rc.d if it exist. - Rewrite postinst++ to enable insserv if it is safe to do so, and drop the code to migrate back. Flag the migration using /var/lib/insserv/using-insserv. - Make sure sysv-rc depend on new enough initscripts (>= 2.86.ds1-63) and sysvinit-utils (>= 2.86.ds1-62) packages for dependency based boot sequencing to work. - Update the dependency on insserv to (>> 1.12.0-10), to get a version without the enabling stuff. This should still make sure systems using sysv-rc with insserv keep using sysv-rc with insserv during and after the upgrade. I am still stuck with the /usr/sbin/update-rc.d-insserv script left behind in the insserv package, and I assume it will only be safe to remove in Squeeze+1 (or +2 if we are to support skipping a version during upgrades). I'm not sure I really need the conflict. Did I forget anything? If I understand this correctly, the upgrade when insserv is enabled, will be done in this sequence, and each ... represent when other packages might be configured and a working update-rc.d need to be provided. Unpack insserv - symlink to /usr/sbin/update-rc.d-insserv is kept ... Unpack sysv-rc - provides /usr/sbin/update-rc.d which work with insserv ... Configure insserv ... Configure sysv-rc - divert to /usr/sbin/update-rc.d-insserv is removed Happy hacking, -- Petter Reinholdtsen _______________________________________________ initscripts-ng-devel mailing list initscripts-ng-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/initscripts-ng-devel