On Sat, 16 Apr 2011, Roger Leigh wrote:
On Sat, Apr 16, 2011 at 05:58:19PM +0100, Edward Allcutt wrote:I suggest: - on upgrade, bind mount or symlink /run/init -> /lib/init/rw - on boot, after mounting /run, mkdir /run/init; ln -s /run/init /lib/init/rw Or in other words - exactly like we're handling /var/lock and /dev/shm except without a possible separate tmpfs. This keeps /lib/init/rw available at all times and doesn't require any particular upgrade order. The link could be dropped in wheezy+1 but there's no urgency to do so. I was under the impression that this was already part of the plan, did /run/init get dropped for some reason?It did. The general consensus was that if we did bind mount /run/init to /lib/init/rw on boot (and vice versa on initial install, as for the othe locations), we would still need to transition from /run/init to /run anyway, so we might as well transition directly from /lib/init/rw to /run in a single shot. This is unlike the other directories, where the files are linked directly to their final destinations.
I see. I don't see how this can be done in a single shot though. Let's take the example of package P which currently keeps state in /lib/init/rw/P. It has version P1 in squeeze. For version P2 in wheezy it aims to move that state to /run/P. The plan is for packages that will use /run in wheezy to predepend on initscripts (>= X). To achieve this, P (version P2) has to Pre-Depend: initscripts (>= X). Because initscripts intends to forcibly move /lib/init/rw/* to /run/* you're proposing that initscripts will Breaks: P (<< P2). I'm hoping I've misunderstood somewhere because that sure looks like an unbreakable cycle to me... If /run/init has been inextricably vetoed then the safe option looks like leaving /lib/init/rw alone in wheezy and letting all relevant packages handle their own transition to /run. If we want to try hard to remove /lib/init/rw in wheezy+1 then we need RC bugs against packages using it which don't safely transition away for wheezy. -- Edward Allcutt