While I applaud the introduction of /run, I have some concerns about how quickly users of alternatives to /run could be required to switch to the new location.
Consider the following scenario. Package P is using /lib/init/rw. At some point the new version of initscripts is installed. The latter's postinst makes /run available, initially as a bind mount of /var/run, post-reboot as a separate tmpfs. OK. But P has not been updated yet; it is still using /lib/init/rw. So initscripts's postinst certainly can't remove /lib/init/rw immediately. What if the latter merely arranges for the removal of /lib/init/rw after the next reboot? Then if the admin reboots, P is broken after the reboot until it gets upgraded. But if P is some kind of infrastructure package then its breakage could cause the administrator anguish. Note that P's maintainer can't do anything about this problem because it is the squeeze version of P that gets broken. The squeeze version of P simply didn't expect that /lib/init/rw would suddenly disappear. I suppose the new initscripts could Conflict with P in order to force upgrade of P at the same time as initscripts; but this makes the upgrade process more rigid and fragile. If the upgrade fails for one reason or another after initscripts has been installed then, again, P is broken after reboot until it gets upgraded. But does the system still have access to the network? I think that P should be allowed to continue using /lib/init/rw at least until the wheezy version of its postinst runs. But this occurs after initscripts's postinst runs. And that is the last chance initscripts has to eliminate /lib/init/rw in wheezy. So I conclude that initscripts should only eliminate /lib/init/rw in wheezy+1. -- Thomas Hood -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/banlktikb9w+-mirnnceykt1z2wk01tm...@mail.gmail.com