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

[Martin Schlemmer]

On Mon, 2002-03-11 at 22:44, Yannick Koehler wrote:
> Matt Beland wrote:
> > On Mon, Mar 11, 2002 at 01:16:45PM -0500, Yannick Koehler wrote:
> >
> >>Craig M. Reece wrote:
> >>
> >>>On Mon, Mar 11, 2002 at 12:48:08PM -0500, Yannick Koehler spoke thusly:
> >>>
> >>>
> >>>>Guys,
> >>>>
> >>>>	not sure for anyone else but is init.d really need to be protected?
> >>>>	I mean does someone really change files in that directory (other
> >>>>	than adding or removing)?
> >>>>
> >>>>	That dir should always get merged.  It would also get really nice of
> >>>>	the portage could detect that no changes has been made to the file
> >>>>	since its installation and therefore merge it without any issues.
> >>>>
> >>>>	Like if the protected config file's time were saved in a temp files
> >>>>	that portage would look into before merging to see if the date has
> >>>>	or not change since the last install.
> >>>>
> >>>>
> >>>>
> >>>Yes it needs to be protected. I, for instance, have my own version of
> >>>pcmcia in there that I don't want stepped on. Also, I have a couple of
> >>>other custom scripts for things not in portage yet; and when they are in
> >>>portage, I want to be able to compare the differences before using one
> >>>or the other.
> >>>
> >>The reasoning I have is that those are scripts, and not config files.
> >>If ... instead of modifying pcmcia script for example like you
> >>mentionned you were to cp pcmcia pcmcia.modif and rc-update add
> >>pcmcia.modif default / rc-update del pcmcia default the system would
> >>work and you'll never get concerned about the new pcmcia scripts.
> >>
> >
> > 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).
>

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.

> >>If you changes those scripts maybe it's even better to tell people about
> >>your changes as they may get implemented such that the script itself
> >>read a config files (like net.eth0) so that other people can re-use your
> >>modifications.
> >>
> >
> > 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?
>
> 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 wouldn't solve the problem for custom scripts. Suppose (as an example)
> > that I have installed OpenSSH by compiling it from source, then later
> > I emerge the ssh ebuild. I would have installed an initscript already,
> > I would call it 'sshd' by default. Before I blindly replace it with the
> > Gentoo initscript, I would want to examine it and see how it did things.
> >
>
>
> see above
>
> >>And maybe a user's scripts directory should exists, something like
> >>/etc/user.d where people can move their custom scripts and the stuff
> >>behind rc-update would got here first and if it doesn't found the script
> >>then to /etc/init.d.
> >>
> >
> > While I don't agree with everything that "the standard linux" build does,
> > particularly as defined in the LSB project, I don't think we should be
> > creating new directories within /etc/ just to make things a little more
> > convenient. Especiually when that convenience comes with a price in the
> > form of an increased risk of system breakage.
>
> 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.
>
> Yannick Koehler
>
>
>
>
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@g.o
> http://lists.gentoo.org/mailman/listinfo/gentoo-dev
-- 

Martin Schlemmer
Gentoo Linux Developer, Desktop Team Developer
Cape Town, South Africa