Re: [gentoo-dev] /etc/init.d

[Matt Beland <matt@rearviewmirror.org>]

[-- Attachment #1: Type: text/plain, Size: 5175 bytes --]

On Mon, Mar 11, 2002 at 11:10:14PM +0200, Martin Schlemmer wrote:
> On Mon, 2002-03-11 at 22:44, Yannick Koehler wrote:
> > Matt Beland wrote:
> > > <snip>
> > > They are sometimes both scripts and config files. Personally, I like the 
> > > layout of the Gentoo initscripts, particularly with regard to the "local"
> > > script and the ability to start "simple" daemons and scripts with a config
> > > file. However, many of the scripts we add to the init.d directory are not
> > > custom-written for Gentoo, they're written for Linux in general. They 
> > > include the necessary config settings in the init file itself. And those
> > > should not be clobbered.
> > >  
> > 
> > While I understand that by having seen some of those scripts in the 
> > past, I don't see a reason not to either do work by removing those 
> > 'config' part and moving them to a /etc/ file and then committing a 
> > patch into gentoo or the original package owner.  I'm pretty sure doing 
> > so wouldn't be considered gentoo either.  I've seen some distro doing 
> > that inside most of their init scripts in order to ensure no one play 
> > with them directely and kind of filtering the dangerous settings from 
> > the config file (always by warning the end-user thought through a log or 
> > something like that).
> > 

But we're not talking about Gentoo init scripts, necessarily. If the script was
installed by some program, and there's no build for it nor is there any real
interest in creating an ebuild for it, then why create a config file and all of
this extra effort you're proposing for what may be a very simple script. If
the program is not part of an ebuild, you might not notice emerge clobbering
your script thanks to an unfortunate collision in the script name.

> Once again ... if you have everthing latest, you should not need to edit
> a file in /etc/init.d/ .  All the config settings is in /etc/conf.d/ .
> This should anyhow go for most users who do not have a unusual setup.

I am not necessarily referring to Gentoo programs or scripts. I am aware that
the Gentoo init scripts, as designed, do not require any protection. The issue
is init scripts that are created for some other daemon not installed as part
of Gentoo potentially being clobbered by a Gentoo-installed script.

<snip>
> > > That's fine for things like the tweaked pcmcia script - but what if the 
> > > tweaks are in order to permit a specific driver to work properly? Those 
> > > changes should not be in the default initscript, they should at most be
> > > provided as a commented-out section - which, again, would require user 
> > > intervention to create the required "tweaked" script.
> > 
> > I don't agree here.  If you have script that make a piece of hardware 
> > work they should get committed inside Gentoo.  Otherwise other people 
> > that have the same issues won't be able to make it work either.  If it's 
> >   for a specific hardware combination then why making all other users 
> > spend their time diff/mv files while you'll be the only one with that 
> > problem?

Because this is *one example* of an issue which creates problems. It is not 
an exclusive problem where this is the only time it would create a problem.

I updated my workstation and two test Gentoo boxes last night, including 
baselayout changes. It took an extra minute maximum per box to look through
the scripts, identify the two that might be a problem, and update the rest.
I hardly think that's a terrible burden to assume.

> > Also having something like I mentionned called user.d where you could 
> > put your own script file would be resolving that.  Maybe even better 
> > would be to have gentoo write scripts by default to system.d and have 
> > symlink inside init.d so that if it attempt to copy a script inside 
> > init.d and see that it's not a  link to a system.d files then it doesn't 
> > override it and warn instead.  The whole idea could also be used for the 
> > /etc folder completely.

It would resolve the problem but break compatability with every other Linux 
distribution. 

> > <snip>
> > Actually I think the opposite.  Convenience for me is really important. 
> >   The less I have to do the more I'm happy and can do something else. 
> > That's why I'm complaining at the first place.  I've merge a couple of 
> > time baselayout and while this package shouldn't be updated frequentely 
> > IMHO it shouldn't be kept idle either if it can still be enhanced. 
> > Therefore I think to make the thing more convenient and less annyoing we 
> > should enhance it a little more.

Quite franky, convenience should never be given priority in cases like this.
System updates should be as convenient as possible *without compromising the
system*. We're not talking about making it easier to read your email, we're
talking about modifying a core system directory with files that are critical
to the proper operation of the system. Convenience is and should always in
such cases be secondary to stability and security.

-- 
Matt Beland
matt@rearviewmirror.org
http://www.rearviewmirror.org

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]