[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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.


  .''`.  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

Reply to: