On Sun, Apr 17, 2011 at 07:44:55AM +0200, Goswin von Brederlow wrote: > Edward Allcutt <edward@allcutt.me.uk> writes: > > > 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. > > Breaks isn't Conflicts. The update happens in the following order: > > deconfigure P > unpack initscripts > configure initscripts > unpack P > configure P > > Breaks only forces package managers to update the broken packages. It > doesn't cause unbreakable cycles. I think that Edward is right that /lib/init/rw would need to be around for longer. We have initscripts in three states 1) [current] provides /lib/init/rw 2) [new] provides /lib/init/rw and /run 3) [future] provides /run only Packages transitioning to use /run on a live system need to move their state from /lib/init/rw to /run. This requires (2), which they get with a versioned dependency. But we can't get to (3) before wheezy is released because this would result in going from (1) to (3) directly, which would prevent a clean transition. Those tracking testing/unstable would be OK, but squeeze→wheezy would not be. This is not to say we couldn't remove it on startup though. Thinking about it, if we did go from (1) to (3) directly, with /lib/init/rw being dropped, the /lib/init/rw mount would not be removed on upgrade. If we have the appropriate Breaks, this will ensure all users are upgraded to use /run, and /lib/init/rw can be removed at the next reboot. I'm not averse to actually moving /lib/init/rw to /run/init should this help with the above. If nothing else, it frees up the mount point to allow its removal later on. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
Attachment:
signature.asc
Description: Digital signature