FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 04-16-2011, 10:39 AM
Thomas Hood
 
Default Only forbid use of old alternatives to /run in wheezy+1?

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


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: BANLkTikB9W+-MiRnnceYkt1z2Wk01TmGdw@mail.gmail.com">http://lists.debian.org/BANLkTikB9W+-MiRnnceYkt1z2Wk01TmGdw@mail.gmail.com
 
Old 04-16-2011, 11:21 AM
rleigh
 
Default Only forbid use of old alternatives to /run in wheezy+1?

On Sat, Apr 16, 2011 at 12:39:03PM +0200, Thomas Hood wrote:
> 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.

/lib/init/rw isn't going to just disappear without coping with this
scenario. Given the low number of users of /lib/init/rw, it's quite
possible that we can just add a list of Breaks: P (<< fixed-version)
for each of the packages concerned (where fixed-version is the
version which switches to /run). This will ensure they are all using
/run before we remove /lib/init/rw.

We haven't made any plans to remove it yet. We'll look more closely
at the best way to do that once all the users are moved over. Given
the small number, it's quite likely this won't take very long. If
it turns out that there are other users of /lib/init/rw, it's not a
problem keeping it around for wheezy. But if there aren't, there's
no need to retain it.

If there is a cleaner method than using versioned Breaks, I'm sure we
can look at that instead--nothing concrete is planned yet for the
removal, so all suggestions are welcome.


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.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110416112132.GC13995@codelibre.net">http://lists.debian.org/20110416112132.GC13995@codelibre.net
 
Old 04-16-2011, 04:58 PM
Edward Allcutt
 
Default Only forbid use of old alternatives to /run in wheezy+1?

On Sat, 16 Apr 2011, rleigh wrote:

We haven't made any plans to remove it yet. We'll look more closely
at the best way to do that once all the users are moved over. Given
the small number, it's quite likely this won't take very long. If
it turns out that there are other users of /lib/init/rw, it's not a
problem keeping it around for wheezy. But if there aren't, there's
no need to retain it.

If there is a cleaner method than using versioned Breaks, I'm sure we
can look at that instead--nothing concrete is planned yet for the
removal, so all suggestions are welcome.


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?

--
Edward Allcutt


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: alpine.DEB.2.00.1104161750130.30901@pandora.retros nub.co.uk">http://lists.debian.org/alpine.DEB.2.00.1104161750130.30901@pandora.retros nub.co.uk
 
Old 04-16-2011, 05:10 PM
Roger Leigh
 
Default Only forbid use of old alternatives to /run in wheezy+1?

On Sat, Apr 16, 2011 at 05:58:19PM +0100, Edward Allcutt wrote:
> On Sat, 16 Apr 2011, rleigh wrote:
> >We haven't made any plans to remove it yet. We'll look more closely
> >at the best way to do that once all the users are moved over. Given
> >the small number, it's quite likely this won't take very long. If
> >it turns out that there are other users of /lib/init/rw, it's not a
> >problem keeping it around for wheezy. But if there aren't, there's
> >no need to retain it.
> >
> >If there is a cleaner method than using versioned Breaks, I'm sure we
> >can look at that instead--nothing concrete is planned yet for the
> >removal, so all suggestions are welcome.
>
> 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.

The number of packages making use of /lib/init/rw is tiny (33), so it
was thought that it could be removed fairly speedily as soon as the
transition can begin. Of those, 16 use the sendsigs.d interface
(trivial mv in postinst), 3 are just documentation/examples. The others
can also be done fairly simply, while I haven't looked at all of them,
most can simply just mv any files in their postinst (with a versioned
dependency on initscripts).


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.
 
Old 04-16-2011, 05:50 PM
Edward Allcutt
 
Default Only forbid use of old alternatives to /run in wheezy+1?

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


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: alpine.DEB.2.00.1104161837100.30901@pandora.retros nub.co.uk">http://lists.debian.org/alpine.DEB.2.00.1104161837100.30901@pandora.retros nub.co.uk
 
Old 04-17-2011, 05:44 AM
Goswin von Brederlow
 
Default 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


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87vcydzb1k.fsf@frosties.localnet">http://lists.debian.org/87vcydzb1k.fsf@frosties.localnet
 
Old 04-17-2011, 08:49 AM
Roger Leigh
 
Default 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.


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.
 
Old 04-17-2011, 08:07 PM
Thomas Hood
 
Default Only forbid use of old alternatives to /run in wheezy+1?

> This is not to say we couldn't remove it on startup though.


You should not remove /lib/init/rw on the next reboot. If the
upgrade stops due to an error then the system might be rebooted
before the upgrade is continued. /lib/init/rw needs to remain
present until all packages using it have been upgraded to wheezy.
Only the wheezy+1 version of initscripts is in a position to
assume that all other packages have been upgraded to wheezy.

You can try to force things using Breaks and other tricks but
I don't see the reason to complicate things and take risks.
--
Thomas


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4DAB4881.9060403@gmail.com">http://lists.debian.org/4DAB4881.9060403@gmail.com
 

Thread Tools




All times are GMT. The time now is 12:54 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org