[Petter Reinholdtsen] > 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.
When using dpkg to install both new versions in a sid chroot, the ordering was actually different. I assume the conflict affected that ordering: # dpkg -i sysv-rc_2.87dsf-3_all.deb insserv_1.12.0-11_i386.deb (Reading database ... 8230 files and directories currently installed.) Preparing to replace sysv-rc 2.87dsf-2 (using sysv-rc_2.87dsf-3_all.deb) ... Unpacking replacement sysv-rc ... Preparing to replace insserv 1.12.0-10 (using insserv_1.12.0-11_i386.deb) ... Unpacking replacement insserv ... Setting up insserv (1.12.0-11) ... Setting up sysv-rc (2.87dsf-3) ... # If I could be sure no other packages postinst would be called between insserv is unpacked and configured, we could drop update-rc.d-insserv. If not, I see no way to avoid keeping it for a long time, until every user of insserv today have upgraded to the new version of sysv-rc. :/ 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
