Only forbid use of old alternatives to /run in wheezy+1?

[Thomas Hood <jdthood@gmail.com>]

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