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

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



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.

MfG
        Goswin


Reply to: