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 06-27-2012, 09:13 AM
Roger Leigh
 
Default Future of update-rc.d in wheezy+1

Hi folks,

I'd just like to briefly discuss potential plans for update-rc.d
in wheezy+1, and how this might impact on file-rc and sysv-rc.

sysv-rc has defaulted to using LSB header dependencies and insserv
for a few years now. The last few releases require you to enable
insserv to upgrade, and the pending upload just does this
automatically. The result is that all wheezy users of sysv-rc
will be using dependency-based boot.

This means that the runlevels and sequence numbers passed as
arguments to update-rc.d will never be used; they will just get
silently discarded. The main problem as I see it is that these
numbers are going to bitrot badly--they aren't being tested, while
the dependency information in the header is being used by everyone.

I'd like to suggest that we do the following in sysv-rc update-rc.d:
- wheezy: silently drop start|stop sequence numbers and runlevels
(this is already the case when using insserv, and we can remove the
non-insserv codepaths)
- wheezy+1: warn if these options are used
- wheezy+2: remove support for the options and error out if used
And additionally, to add lintian warnings for use of these options,
including when using dh_installinit.

The main problem that I can see is file-rc is currently still
dependent upon the sequence numbers and runlevel information. Would
it be possible for file-rc to also add support for dependencies?
Given that the static boot ordering is quite dead at this point, it
would be very helpful to know what's possible here. Could it use
insserv to do the dependency graph and then just consume the
makefile-style dependency list?


Regards,
Roger

--
.'`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120627091329.GJ9135@codelibre.net">http://lists.debian.org/20120627091329.GJ9135@codelibre.net
 
Old 06-27-2012, 09:27 AM
Petter Reinholdtsen
 
Default Future of update-rc.d in wheezy+1

[Roger Leigh]
> Could [file-rc] use insserv to do the dependency graph and then just
> consume the makefile-style dependency list?

Yes. See <URL: http://bugs.debian.org/539591 >,
<URL: http://bugs.debian.org/573004 > and the source of insserv, where
a patch to do this was created and included by Kel. The patch has
been available for more than two years.

--
Happy hacking
Petter Reinholdtsen


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120627092719.GB20167@login2.uio.no">http://lists.debian.org/20120627092719.GB20167@login2.uio.no
 
Old 06-27-2012, 01:28 PM
Paul Wise
 
Default Future of update-rc.d in wheezy+1

On Wed, Jun 27, 2012 at 6:27 PM, Petter Reinholdtsen wrote:

> Yes. *See <URL: http://bugs.debian.org/539591 >,
> <URL: http://bugs.debian.org/573004 > and the source of insserv, where
> a patch to do this was created and included by Kel. *The patch has
> been available for more than two years.

Hmm, no upload in those two years either. Is file-rc still maintained at all?

--
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CAKTje6FoqHOvi6zaE6YX-cBoL81zLXVKUJZxCgghVPmntgASdw@mail.gmail.com">http ://lists.debian.org/CAKTje6FoqHOvi6zaE6YX-cBoL81zLXVKUJZxCgghVPmntgASdw@mail.gmail.com
 
Old 06-27-2012, 01:46 PM
Alexander Wirt
 
Default Future of update-rc.d in wheezy+1

On Wed, 27 Jun 2012, Paul Wise wrote:

> On Wed, Jun 27, 2012 at 6:27 PM, Petter Reinholdtsen wrote:
>
> > Yes. *See <URL: http://bugs.debian.org/539591 >,
> > <URL: http://bugs.debian.org/573004 > and the source of insserv, where
> > a patch to do this was created and included by Kel. *The patch has
> > been available for more than two years.
>
> Hmm, no upload in those two years either. Is file-rc still maintained at all?
It is. But more or less in "no-new-features" mode.

Implementing the insserv stuff is wishlist for me. Even when I now get forced
into it.

Alex


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120627134633.GC6041@snow-crash.org">http://lists.debian.org/20120627134633.GC6041@snow-crash.org
 
Old 06-27-2012, 02:39 PM
Bernd Zeimetz
 
Default Future of update-rc.d in wheezy+1

On 06/27/2012 03:46 PM, Alexander Wirt wrote:
> On Wed, 27 Jun 2012, Paul Wise wrote:
>
>> On Wed, Jun 27, 2012 at 6:27 PM, Petter Reinholdtsen wrote:
>>
>>> Yes. See <URL: http://bugs.debian.org/539591 >,
>>> <URL: http://bugs.debian.org/573004 > and the source of insserv, where
>>> a patch to do this was created and included by Kel. The patch has
>>> been available for more than two years.
>>
>> Hmm, no upload in those two years either. Is file-rc still maintained at all?
> It is. But more or less in "no-new-features" mode.
>
> Implementing the insserv stuff is wishlist for me. Even when I now get forced
> into it.

So might be this could avoided if we switch to something more modern
like openrc as discussed some weeks ago here - I think the main reason
file-rc edxists is because its much more easy to maintain than all the
other crap^Winit systems (including insserv) floating around.


--
Bernd Zeimetz Debian GNU/Linux Developer
http://bzed.de http://www.debian.org
GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4FEB1B2A.3080308@bzed.de">http://lists.debian.org/4FEB1B2A.3080308@bzed.de
 
Old 06-27-2012, 09:54 PM
Roger Leigh
 
Default Future of update-rc.d in wheezy+1

On Wed, Jun 27, 2012 at 04:39:38PM +0200, Bernd Zeimetz wrote:
> On 06/27/2012 03:46 PM, Alexander Wirt wrote:
> > On Wed, 27 Jun 2012, Paul Wise wrote:
> >
> >> On Wed, Jun 27, 2012 at 6:27 PM, Petter Reinholdtsen wrote:
> >>
> >>> Yes. See <URL: http://bugs.debian.org/539591 >,
> >>> <URL: http://bugs.debian.org/573004 > and the source of insserv, where
> >>> a patch to do this was created and included by Kel. The patch has
> >>> been available for more than two years.
> >>
> >> Hmm, no upload in those two years either. Is file-rc still maintained at all?
> > It is. But more or less in "no-new-features" mode.
> >
> > Implementing the insserv stuff is wishlist for me. Even when I now get
> > forced into it.

I don't think there's any question of "forcing", but encouraging
file-rc to retain compatibility with the init scripts being used by the
distribution. It looks like the patches are there, they just need
testing. If file-rc could have this in place for wheezy, that would
be highly desirable, so that we can work on deprecating runlevel
sequence numbers in wheezy+1.

> So might be this could avoided if we switch to something more modern
> like openrc as discussed some weeks ago here - I think the main reason
> file-rc edxists is because its much more easy to maintain than all the
> other crap^Winit systems (including insserv) floating around.

The openrc runscript format is certainly a bit nicer than the LSB
header, but at the same time has some disadvantages. With the LSB
header/insserv setup, we can read all the headers and have a
dependency graph for all the scripts. But when you run a script by
hand, or with invoke-rc.d, it can't satisfy dependencies at that
point--it's only at the level of /etc/init.d/rc for runlevel changes.
OpenRC OTOH has no global view but can resolve dependencies
iteratively when running a script directly. Having both would be
nice, which is what systemd/upstart give us.

I'm still following OpenRC stuff, though I've not had time to get
involved directly yet. The main point preventing us adopting it is
lack of support for LSB dependencies, which would make upgrades
rather painful. We could possibly address this by autogeneration of
runscript wrappers for LSB scripts. Ideally, I'd like for OpenRC to
gain a high level dependency graph view of the system, but it doesn't
look like this is a design that would be particularly popular with
OpenRC upstream.


Regards,
Roger

--
.'`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120627215404.GN9135@codelibre.net">http://lists.debian.org/20120627215404.GN9135@codelibre.net
 
Old 06-28-2012, 06:02 AM
Alexander Wirt
 
Default Future of update-rc.d in wheezy+1

On Wed, 27 Jun 2012, Roger Leigh wrote:

> On Wed, Jun 27, 2012 at 04:39:38PM +0200, Bernd Zeimetz wrote:
> > On 06/27/2012 03:46 PM, Alexander Wirt wrote:
> > > On Wed, 27 Jun 2012, Paul Wise wrote:
> > >
> > >> On Wed, Jun 27, 2012 at 6:27 PM, Petter Reinholdtsen wrote:
> > >>
> > >>> Yes. See <URL: http://bugs.debian.org/539591 >,
> > >>> <URL: http://bugs.debian.org/573004 > and the source of insserv, where
> > >>> a patch to do this was created and included by Kel. The patch has
> > >>> been available for more than two years.
> > >>
> > >> Hmm, no upload in those two years either. Is file-rc still maintained at all?
> > > It is. But more or less in "no-new-features" mode.
> > >
> > > Implementing the insserv stuff is wishlist for me. Even when I now get
> > > forced into it.
>
> I don't think there's any question of "forcing", but encouraging
> file-rc to retain compatibility with the init scripts being used by the
> distribution. It looks like the patches are there, they just need
> testing. If file-rc could have this in place for wheezy, that would
> be highly desirable, so that we can work on deprecating runlevel
> sequence numbers in wheezy+1.
Nope, there is an experimental patch for insserv to print out sequence
numbers, to get this working I first have to build my own insserv. And the
whole file-rc part is - beside of some ideas in my mind - missing.

So its unlikely to get this working unless insserv (for the patch) and
file-rc get a freeze exception.

Alex


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120628060233.GF6041@snow-crash.org">http://lists.debian.org/20120628060233.GF6041@snow-crash.org
 
Old 06-28-2012, 08:44 AM
Goswin von Brederlow
 
Default Future of update-rc.d in wheezy+1

Roger Leigh <rleigh@codelibre.net> writes:

> Hi folks,
>
> I'd just like to briefly discuss potential plans for update-rc.d
> in wheezy+1, and how this might impact on file-rc and sysv-rc.
>
> sysv-rc has defaulted to using LSB header dependencies and insserv
> for a few years now. The last few releases require you to enable
> insserv to upgrade, and the pending upload just does this
> automatically. The result is that all wheezy users of sysv-rc
> will be using dependency-based boot.
>
> This means that the runlevels and sequence numbers passed as
> arguments to update-rc.d will never be used; they will just get
> silently discarded. The main problem as I see it is that these
> numbers are going to bitrot badly--they aren't being tested, while
> the dependency information in the header is being used by everyone.
>
> I'd like to suggest that we do the following in sysv-rc update-rc.d:
> - wheezy: silently drop start|stop sequence numbers and runlevels
> (this is already the case when using insserv, and we can remove the
> non-insserv codepaths)
> - wheezy+1: warn if these options are used
> - wheezy+2: remove support for the options and error out if used
> And additionally, to add lintian warnings for use of these options,
> including when using dh_installinit.
>
> The main problem that I can see is file-rc is currently still
> dependent upon the sequence numbers and runlevel information. Would
> it be possible for file-rc to also add support for dependencies?
> Given that the static boot ordering is quite dead at this point, it
> would be very helpful to know what's possible here. Could it use
> insserv to do the dependency graph and then just consume the
> makefile-style dependency list?
>
>
> Regards,
> Roger

You say the numbers are going to bitrot, which I totaly agree. But that
could be prevented.

The numbers specified for update-rc.d must be well ordered according to
the dependencies specified in the LSB headers. That means that that
update-rc.d could keep a record of the numbers specified and check that
the numbers are valid even though sysv-rc/insserv then ignore them.

This check could also be done as archive wide check using piuparts or
something. Doesn't have to be done on every users systems.

MfG
Goswin


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/871ukzn7ui.fsf@frosties.localnet
 
Old 06-28-2012, 09:52 AM
Roger Leigh
 
Default Future of update-rc.d in wheezy+1

On Thu, Jun 28, 2012 at 10:44:53AM +0200, Goswin von Brederlow wrote:
> Roger Leigh <rleigh@codelibre.net> writes:
>
> > This means that the runlevels and sequence numbers passed as
> > arguments to update-rc.d will never be used; they will just get
> > silently discarded. The main problem as I see it is that these
> > numbers are going to bitrot badly--they aren't being tested, while
> > the dependency information in the header is being used by everyone.

> You say the numbers are going to bitrot, which I totaly agree. But that
> could be prevented.
>
> The numbers specified for update-rc.d must be well ordered according to
> the dependencies specified in the LSB headers. That means that that
> update-rc.d could keep a record of the numbers specified and check that
> the numbers are valid even though sysv-rc/insserv then ignore them.

While we could expend the time and effort to do this, I do have to
question why. What would be the point of this? No one is using
those numbers, so why retain them? It seems, to me, to be an
entirely pointless waste of valuable developer time. And not just my
time, but for every developer who would need to continue to test and
validate the numbers for their scripts.

We have dependencies for a reason, and the sequence numbers are now
nothing more than a historical artifact.


Regards,
Roger

--
.'`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120628095223.GS9135@codelibre.net">http://lists.debian.org/20120628095223.GS9135@codelibre.net
 
Old 06-28-2012, 10:09 AM
 
Default Future of update-rc.d in wheezy+1

On Jun 28, Roger Leigh <rleigh@codelibre.net> wrote:

> While we could expend the time and effort to do this, I do have to
> question why. What would be the point of this? No one is using
> those numbers, so why retain them?
Agreed.

--
ciao,
Marco
 

Thread Tools




All times are GMT. The time now is 05:49 AM.

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