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

[Yannick Koehler <yannick.koehler@colubris.com>]

mbutcher wrote:
> Interesting suggestions, but to me your solution looks more complex than the 
> status quo. Now, instead of just merging the files by hand, I have to:

The idea I wrote is more to trigger more thoughts in hope of a better 
system than a real solution.  My goal was to reduce works for most 
people while keeping it the same for the group of people that actually 
customized those.

I'm pretty sure that most people here at first don't like my idea 
because I posted to -dev and therefore most of you will have custom 
scripts.  But, because you have such scripts you already have the work 
of doing the merge therefore you don't lose anything.

And you're more knowledgeable than others who can't/don't know how to 
customize those scripts.  But right now the one who pay are the one who 
don't know.  Because they have to do the merge and they are the newbies.



> 1) Manage another set of scripts in another place (/etc/user.d), which makes 
> troubleshooting harder.

We could actually have it inside the same place (using sym links)

> 2) Deal with another set of config files (If I'm reading your second 
> paragraph correctly), which might break if a new ebuild adds or removes 
> options that this config file must have.

It's not another set of config files.  It's  actually the distro set + 
the one your customized.  So most users will only have the custom sets.

> 3) Worry that any time I update a package, one of the scripts that _was_ 
> playing nicely will now be broken without giving me so much as a warning.

That's true today also, aren't you worry that each time you emerge X11 
it won't work anymore, or that each time you emerge baselayout it may 
break some basic application or binutils etc.. I mean the scripts are 
calling those application but if the application is broke the script 
also gets broke.  I don't see this as a valid arguments for this discussion.

If you claim that the script may get broke more than the program, I 
would not agree with you because I believe they are tested as much as 
the program themselves. (You may think that the program gets more tested 
but it only get tested inside gentoo on the same hardware/config 
platform as the people who also test their scripts.)

> If we used your proposal for '.modif' scripts, then updating a build might 
> never warn us of the changes that _did_ take place, and _should_ be handled 
> differently in the custom script. If we added the functionality to portage to 
> warn us when a config script changed, then... well, we'd be back to where we 
> started.

In that system where we would use sym links, if you customize a script 
and follow instruction, it would let portage detect that the file is a 
symlink and not a file and silently replaced it.  If the file is not a 
symlink then it would act as if it was protected.  Here I'm only talking 
about scripts not config files.  If a scripts is also a config, then I 
would have mark as a bug to split them into a script and a config.

Ideally you want to be warn when you did customize it not when you 
didn't.  Right now the problem is that you always get and I think the 
big issue is that most people that get warns won't even know / figure 
out what to do exactly from that step on.  While the one who customized 
their script will just need a reminder to check it out.

> Also, I'd challenge the claim that 85-90% of Gentoo users do not alter their 
> init scripts. That may be true for Red Hat or Mandrake (though users of those 
> do have to update /etc/sysconfig files instead, which isn't any better to me).

Look, My claim was not a fact.  I think that this distro as great 
potential for anyone that used other linux distro for 1-2 years and are 
tired of waiting for distro update in order to update or try things out. 
  Right now because the distro is below 1.0 I believe that most people 
using it are developers but I also believe that as you guys continue to 
enhance that system it will attract a lot more users who won't be 
developers.  You probably already have seen that with the slashdot 
announcement (which is when I became a gentoo apprentice).

> To me, the attractive part about the way it works now is that it is simple 
> and straightforward. I feel like I am in control of things when I update a 
> package. It took me (and probably most people on this list) a minimal amount 
> of time to learn the scheme, and now I rue the days when I used to spend 
> hours debugging problems in Red Hat init scripts (only to have my fixes 
> overwritten the next time I upgraded with RPM).

Not really related, but feeling in control and being in control are very 
different thing.  While you are in control becausse you can see the 
changes and analyse them think about those that don't know bash or that 
don't know that those scripts even exists, they won't even know why the 
new features they installed is not working even after the rc-update 
command has been issued.  They will be even less in control than you 
wanted them to be at first.  I agree it then offer a great opportunity 
to learn but that's what we call the hard way.

I think that scripts should be treated as program, because that's what I 
think they are.  If you silentely update program then why not silentely 
update scripts as well.  That is my original issue.  For some people 
customizing program is as frequent as the scripts themselves, would you 
warn them about each program modified? I don't think so, because they 
probably know their stuff.  Therefore I think the same should apply to 
scripts.

> I understand that the current way might slow you down if you're running a lot 
> of services. But to me, that's a small price to pay for soundness of mind and 
> simple elegance.

I'm really happy with the distro, and I'm just trying to find spot for 
more enhancements.  I even had realy hard time figuring out that one :-) 
because the distro is already great.

Yannick Koehler