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

[Yannick Koehler]

Matt Beland wrote:
> On Mon, Mar 11, 2002 at 02:32:24PM -0500, Yannick Koehler wrote:
> They are not more important, than the binaries, but they are far more likely
> to have been modified by the end user. If the end user has modified the
> binary, then they almost certainly are not using the ebuild. However, if all
> I want/need to do is modify the initscript, then I'm not going to go to the
> added hassle of manually tracking the program just because I use a different
> init from that provided by the ebuild.

I think that gentoo's ebuild system open the doors to customized 
binaries.  That's actually why I like gentoo so much, I can grab an 
ebuild, run ebuild <put your name>.ebuild extract, then customize the 
source code and do the rest compile/install/qmerge.  It's even more 
simpler than ./configure && make && make install because it will 
override my previous files and I'm sure not to have duplicates.

So in my case its exactly the reverse that occurs, I have more binaries 
customized than scripts inside /etc/init.d.  I recentely changes my 
syslog-ng to strip the program name from the $MSG macro because I 
already had a $PROGRAM macro displaying its name.  I sent the patch to 
the owner meanwhile I have my version running.  I fixed some issues 
inside my mozilla because I knew that code.  I changed the way some 
other binaries worked too to my liking.  Now I know what I did and it's 
easy for me to re-emerge that stuff.  But inside /etc I had to modify 
files which I don't know all, some where modified by program which I 
have no idea what exactly they did until I read their manual.  So I 
can't blind copy new files.  I have to do the merge but last time my 
merge could have been 7 files instead of 35. and the previous time 5 
instead of 24.  etc..  And I expect not to be the only one which means 
that you can multiply that by a big number.  So I think there's place in 
there for enhancement.

>
>>Therefore I think they should be treated the same.  Now they are treated
>>as config file and require end-users intervention when I don't see a
>>reason for most end-user.  Like programs, some users will modify their
>>program by using personnaly modified source tree and those would know
>>not to put the binary or merge those package.
>>
>
> They are treated as a config file because they are a config file. They control
> how the binaries are started, how they're stopped, and how they're tracked
> while running. The current behavior is the proper behavior.

 From what I understand from a previous post, the config of those 
scripts are in /etc/conf.d and not inside the scripts themselves.

>
>>Actually I think it's even worse treating those files as config.
>>Because new users, the one that you always want to get in a distro may
>>be running pretty old script as they may not be aware on how to do the
>>merge step manually.
>>
>
> I understand the point behind being newbie-friendly, and the arguments for
> making something "easier for new users", but I have to disagree in this case.
> You're advocating making the system easier for a new user while making life
> more difficult for an advanced user. Quite frankly, that's why many of us
> *moved* to Gentoo over RedHat or one of the other distributions - they make
> life easier for new users at the expense of some of the innate power and
> flexibility of Unix.
>
>

End-users that modify their scripts should use either different names or 
  backup them.  As most people do about original works.  I don't agree 
it make their life more complicated because anyway those people knows 
more and won't look forever at the cause of their problems compares to 
newbies.

Yannick Koehler