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 03-18-2009, 01:35 PM
Jan Wagner
 
Default Transition of initscripts to new order / sequence number

Hi there,

while thinking about how to solve #508189, where I need to change the position
of the initscript in bootorder, I thought it would not sufficient to change
only the call of dh_installinit in the rules file.

If an user changed the symlinks, I guess I will break his changes. How should
we handle this? Is there any best practise and/or policy how we should deal
with it? I think it's not usefull just to override the changes by the local
sysadmin.

Thanks for your hints, Jan.
--
Never write mail to <waja@spamfalle.info>, you have been warned!
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GIT d-- s+: a- C+++ UL++++ P+ L+++ E- W+++ N+++ o++ K++ w--- O M V- PS PE
Y++ PGP++ t-- 5 X R tv- b+ DI- D++ G++ e++ h-- r+++ y+++
------END GEEK CODE BLOCK------
 
Old 03-21-2009, 10:13 PM
Petter Reinholdtsen
 
Default Transition of initscripts to new order / sequence number

[Jan Wagner]
> while thinking about how to solve #508189, where I need to change
> the position of the initscript in bootorder, I thought it would not
> sufficient to change only the call of dh_installinit in the rules
> file.

This is the kind of issues the dependency based boot sequencing is
ment to solve. It generate the boot ordering based on dependencies
specified in each init.d script. See
<URL:http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot> for
more info on this effort.

> If an user changed the symlinks, I guess I will break his
> changes. How should we handle this? Is there any best practise
> and/or policy how we should deal with it? I think it's not usefull
> just to override the changes by the local sysadmin.

At the moment, the only option that work with both sysv-rc and file-rc
is to remove all symlinks and reinstall them. This is not a very good
option, but given the limitation of the update-rc.d API, it is the
only one that work.

Kel Modderman has been working on extending the update-rc.d API to
allow for more fine grained adjustment of init.d symlinks, and I hope
it will be available for the next stable release. Until then, no good
and portable option exist. Please see the posts linked from
<URL:http://lists.alioth.debian.org/pipermail/initscripts-ng-devel/2008-September/thread.html>
for more information about the proposed API.

I know some package maintainers handle this by ignoring the existence
of file-rc and just removing symlinks directly in /etc/rcX.d/. As
long as file-rc exist and is supposed in Debian, I believe it is a bad
idea.

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
 
Old 03-21-2009, 11:07 PM
Steve Langasek
 
Default Transition of initscripts to new order / sequence number

On Sun, Mar 22, 2009 at 12:13:37AM +0100, Petter Reinholdtsen wrote:
> I know some package maintainers handle this by ignoring the existence
> of file-rc and just removing symlinks directly in /etc/rcX.d/. As
> long as file-rc exist and is supposed in Debian, I believe it is a bad
> idea.

It seems to me that it would be a lot less effort to fix this by removing
file-rc in Debian, which has only a handful (137) of popcon reports. Even
if we take into consideration that popcon isn't a good source of absolute
numbers, this comes out to .2% of popcon reports that we're spending this
effort on, and for what benefit?

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 03-22-2009, 07:16 AM
Jakub Wilk
 
Default Transition of initscripts to new order / sequence number

* Steve Langasek <vorlon@debian.org>, 2009-03-21, 17:07:

I know some package maintainers handle this by ignoring the existence
of file-rc and just removing symlinks directly in /etc/rcX.d/. As
long as file-rc exist and is supposed in Debian, I believe it is a bad
idea.


It seems to me that it would be a lot less effort to fix this by removing
file-rc in Debian, which has only a handful (137) of popcon reports. Even
if we take into consideration that popcon isn't a good source of absolute
numbers, this comes out to .2% of popcon reports that we're spending this
effort on, and for what benefit?

Benefit of having an abstraction layer.

Keep in mind that lost of users will not install file-rc, even if it is
superior to sysv-rc, because:

- sysv-rc is the default.
- They never heard that alternatives to sysv-rc exist.
- They never had to fiddle with runlevels, so they don't known what
a nuisance it is with sysv-rc.
- If you try to install file-rc, apt displays a big red warning which
suggests that you are doing something utterly wrong.


--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 03-23-2009, 02:20 AM
Steve Langasek
 
Default Transition of initscripts to new order / sequence number

On Sun, Mar 22, 2009 at 09:16:31AM +0100, Jakub Wilk wrote:
>> It seems to me that it would be a lot less effort to fix this by removing
>> file-rc in Debian, which has only a handful (137) of popcon reports. Even
>> if we take into consideration that popcon isn't a good source of absolute
>> numbers, this comes out to .2% of popcon reports that we're spending this
>> effort on, and for what benefit?
> Benefit of having an abstraction layer.

That's not a benefit, that's a burden. You don't abstract things that you
don't *need* to have abstracted.

> - They never had to fiddle with runlevels, so they don't known what
> a nuisance it is with sysv-rc.

As far as I'm concerned, that's an argument for improving the tools for
managing runlevels via sysv-rc, not for changing the update-rc.d API.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 03-23-2009, 11:51 AM
Henrique de Moraes Holschuh
 
Default Transition of initscripts to new order / sequence number

On Sun, 22 Mar 2009, Steve Langasek wrote:
> On Sun, Mar 22, 2009 at 09:16:31AM +0100, Jakub Wilk wrote:
> >> It seems to me that it would be a lot less effort to fix this by removing
> >> file-rc in Debian, which has only a handful (137) of popcon reports. Even
> >> if we take into consideration that popcon isn't a good source of absolute
> >> numbers, this comes out to .2% of popcon reports that we're spending this
> >> effort on, and for what benefit?
> > Benefit of having an abstraction layer.
>
> That's not a benefit, that's a burden. You don't abstract things that you
> don't *need* to have abstracted.

Only, in this case, we need it abstracted (which it already is), and we need
it to _remain_ abstracted.

Otherwise, we will have massive pains to switch initsystems (as in: it will
be either completely impossible, or it will take two or three stable
releases to do it). It was trouble enough to implement invoke-rc.d.

> > - They never had to fiddle with runlevels, so they don't known what
> > a nuisance it is with sysv-rc.
>
> As far as I'm concerned, that's an argument for improving the tools for
> managing runlevels via sysv-rc, not for changing the update-rc.d API.

The update-rc.d API is incomplete. It really needs to be extended, and
that's what people are doing. update-rc.d is a maintainer script API (if
the local admin wants to use it directly, that's his problem). This has
_nothing_ to do with end-user tools for sysv-rc.

No regular package maintainer script has _any_ business dealing with sysv-rc
tools (exceptions are other initscript subsystem packages, sysv-rc packages,
etc). They need to do it over the abstraction layer, so that they will work
with different initscript systems.

--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 03-24-2009, 08:57 AM
Harald Braumann
 
Default Transition of initscripts to new order / sequence number

On Mon, 23 Mar 2009 09:51:09 -0300
Henrique de Moraes Holschuh <hmh@debian.org> wrote:

> Only, in this case, we need it abstracted (which it already is), and
> we need it to _remain_ abstracted.
>
> Otherwise, we will have massive pains to switch initsystems (as in:
> it will be either completely impossible, or it will take two or three
> stable releases to do it). It was trouble enough to implement
> invoke-rc.d.

Who would want to do that, anyway? Why replace a simple working solution
with something complex and overengineered?

It's getting harder and harder to really understand the system because
so many things get replaced by more complex solutions and basic
interfaces are abstracted and thus become inscrutable.

Cheers,
harry
 
Old 03-24-2009, 10:47 PM
Henrique de Moraes Holschuh
 
Default Transition of initscripts to new order / sequence number

On Tue, 24 Mar 2009, Harald Braumann wrote:
> > Otherwise, we will have massive pains to switch initsystems (as in:
> > it will be either completely impossible, or it will take two or three
> > stable releases to do it). It was trouble enough to implement
> > invoke-rc.d.
>
> Who would want to do that, anyway? Why replace a simple working solution
> with something complex and overengineered?

Because what we have right now doesn't work well.

And it doesn't work well mostly because of halfbaked APIs, not because
of complexity or overengineering. Complete APIs means less complexity
and code duplication, and easy to use ones avoid errors.

As a simple example: if we had "restart-if-running" and/or "status"
initscript actions since day one, invoke-rc.d wouldn't have come into
existence (although the chroot issue would need something for the
maintainer scripts anyway, but it could be much simpler).

If update-rc.d had gotten fixed to act like dpkg-divert does early on,
we wouldn't be losing local admin configuration to fix packaging
bugs...

Now that an abstraction layer is finally in place, it is a bad idea to
remove it right away. Instead, make the stuff below it so simple that
the layer can become simple, too.

Only then, after you're sure you have something that really is worty
of being the only choice, should you think about removing the
abstraction layer.

> It's getting harder and harder to really understand the system because
> so many things get replaced by more complex solutions and basic
> interfaces are abstracted and thus become inscrutable.

You mean stuff like udev?

Wait until you get to deal with fully async userspace... Everything
is becoming hotpluggable, and that is something we haven't even begun
to address correctly yet.

--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 03-25-2009, 01:53 AM
Gunnar Wolf
 
Default Transition of initscripts to new order / sequence number

Harald Braumann dijo [Tue, Mar 24, 2009 at 10:57:45AM +0100]:
> > Only, in this case, we need it abstracted (which it already is), and
> > we need it to _remain_ abstracted.
> >
> > Otherwise, we will have massive pains to switch initsystems (as in:
> > it will be either completely impossible, or it will take two or three
> > stable releases to do it). It was trouble enough to implement
> > invoke-rc.d.
>
> Who would want to do that, anyway? Why replace a simple working solution
> with something complex and overengineered?
>
> It's getting harder and harder to really understand the system because
> so many things get replaced by more complex solutions and basic
> interfaces are abstracted and thus become inscrutable.

Because time changes the way things are. SysV-style startup is very
well for a server or workstation - a machine that is basically
always-on and in a stable configuration. If you want your machine to
have a fast startup, you want to parallelize startup as much as
possible - Having a rigidly sorted scheme does not help. Startup
script dependencies help us advance a bit. Having enviromental changes
impact your computer (i.e. new network interfaces coming up, for which
you will have to run several things and might want to start up your
networking, or network interfaces shutting down, which makes running
daemons not useful to have instantiated, or your DHCP lease
expiring/changing which leads to daemons that are bound to a specific
IP to be unreachable) should be handled the best way possible - Right
now we are kludging around it, but an event-based init system _is_ the
way to go for the forseeable future. But we don't want to make things
insta-incompatible, we must go step by step.

--
Gunnar Wolf - gwolf@gwolf.org - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 

Thread Tools




All times are GMT. The time now is 04:02 AM.

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