[gentoo-dev] /etc/init.d

[gentoo-dev] /etc/init.d

[Yannick Koehler]

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.

Yannick Koehler

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

[Matt Beland]

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

On Mon, Mar 11, 2002 at 12:48:08PM -0500, Yannick Koehler wrote:
> 
> 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.

/etc/init.d/ should be protected, if nor no other reason than because it's better 
to err on the side of caution.

I currently have four modified init.d/ scripts, plus three that either I or a 
compiled-from-source program created. If init.d were not protected, and an update
or emerge replaced one of those scripts without my knowledge, it could seriously
hose up parts of the system.

Nope. The current system works fine. At most, someone should be able to easily 
write a script to automatically copy init.d/ scripts into place. 

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

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

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

[Ric Mesier]

Not sure I need /etc/init.d to be touched once I have it working because
I sometimes make minor alterations to files in there that I'd rather not
get clobbered. One thing that frustrated me, tho, was the difficulty in
checking the differences in the new files in /etc. I may actually get up
the ambition to write a script to do a batch diff on all the files in
the various /etc directories.

One thing that did frustrate me while I was looking at the changes
manually was that some files showed very minor diffs. /etc/pwdb.conf
showed alterations on all the lines. Some of them, to my recollection
had the ordering changed and perhaps some spacing that was different. It
might also be useful to know why the changes were made so I can make a
determination as to whether I merge the changes in or not. Or was there
an emerge command for some of this?

Ric


On Mon, 2002-03-11 at 12:48, Yannick Koehler wrote:
> 
> 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.
> 
> Yannick Koehler
> 

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

[Benjamin Ritcey]

On Mon, 2002-03-11 at 12:54, Ric Mesier wrote:
> Not sure I need /etc/init.d to be touched once I have it working because
> I may actually get up
> the ambition to write a script to do a batch diff on all the files in
> the various /etc directories.
> 
> Or was there an emerge command for some of this?
> 
> Ric

Some of it;

emerge gentoolkit
etc-update


HTH,

-b

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

[Ric Mesier]

Thought etc-update applied all the changes pending? Does it also do a
review first? Can't find a man page for it on my system (with gentoolkit
installed -- I couldn't live withouth qpkg .. okay, I could, but it
wouldn't be as fun :-) 

Ric


On Mon, 2002-03-11 at 13:43, Benjamin Ritcey wrote:
> On Mon, 2002-03-11 at 12:54, Ric Mesier wrote:
> 
> Some of it;
> 
> emerge gentoolkit
> etc-update
> 
> 

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

[Ric Mesier]

Never mind. Read through the script. Nice.

Ric

On Mon, 2002-03-11 at 13:45, Ric Mesier wrote:
> Thought etc-update applied all the changes pending? Does it also do a
> review first? Can't find a man page for it on my system (with gentoolkit
> installed -- I couldn't live withouth qpkg .. okay, I could, but it
> wouldn't be as fun :-) 
> 
> Ric
> 
> 
> On Mon, 2002-03-11 at 13:43, Benjamin Ritcey wrote:
> > On Mon, 2002-03-11 at 12:54, Ric Mesier wrote:
> > 
> > Some of it;
> > 
> > emerge gentoolkit
> > etc-update
> > 
> > 
> 
> 
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@gentoo.org
> http://lists.gentoo.org/mailman/listinfo/gentoo-dev

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

[Ian Smith]

Ric Mesier wrote:

> One thing that did frustrate me while I was looking at the changes
> manually was that some files showed very minor diffs. /etc/pwdb.conf
> showed alterations on all the lines. Some of them, to my recollection
> had the ordering changed and perhaps some spacing that was different. It
> might also be useful to know why the changes were made so I can make a
> determination as to whether I merge the changes in or not. Or was there
> an emerge command for some of this?


Perhaps a compromise would be for the developers to postpone formatting 
changes until a genuine functional change is needed?

-- 
----------------------------------------------------------------------------
Ian Smith
----------------------------------------------------------------------------

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

[Craig M. Reece]

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.

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

[Yannick Koehler]

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.
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@gentoo.org
> http://lists.gentoo.org/mailman/listinfo/gentoo-dev
> 

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.

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.

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.

Yannick Koehler

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

[mbutcher]

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:

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

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.

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.

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.

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).

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).

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.

Matt

On Monday 11 March 2002 11:16 am, 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.
> > _______________________________________________
> > gentoo-dev mailing list
> > gentoo-dev@gentoo.org
> > http://lists.gentoo.org/mailman/listinfo/gentoo-dev
>
> 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.
>
> 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.
>
> 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.
>
> Yannick Koehler
>
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@gentoo.org
> http://lists.gentoo.org/mailman/listinfo/gentoo-dev

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

[Craig M. Reece]

On Mon, Mar 11, 2002 at 11:52:55AM -0700, mbutcher spoke thusly:
>
	snippage...
> 
> 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).
>
	more snippage...

This is one of the main reasons I went with LFS and now Gentoo instead
of the other distros.

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

[Yannick Koehler]

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

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

[Matt Beland]

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

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.
 
> 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.

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.

> 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.

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

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

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

[Martin Schlemmer]

On Mon, 2002-03-11 at 20:54, 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 

Just note that as of baselayout-1.7.3 i think, no more rc-scripts have
variables that you set inside the script itself ... they all are in
/etc/conf.d/ .

> 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.
>  
> > 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.
> 
> 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.
> 
> > 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.
> 
> -- 
> Matt Beland
> matt@rearviewmirror.org
> http://www.rearviewmirror.org
-- 

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

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

[Yannick Koehler]

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).

>>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

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@gentoo.org
> http://lists.gentoo.org/mailman/listinfo/gentoo-dev
-- 

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

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

[Matt Beland]

[-- 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 --]

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

[Yannick Koehler]

I now have my solution so I'm mostly arguing just for the fun of it now ;-)


Matt Beland wrote:
> 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.
> 

The same occurs if I create a software and I give it a name and inside a 
package there's a binary with the name which obviously will get over my 
/usr/bin file.  The chance are probably the same.  If you write binary 
you'll have this problem,  if you write script, well... you'll have the 
problem too.  Try to compare both ...  believe it or not I may write 1-2 
utilities for my testing per week and name clashing can occurs as I'm 
not the only one working on the cvs repository we use.  The trick, well, 
I move my stuff into my own folder and I create sym links, the same 
trick can safely be done in /etc/init.d.  I don't see a complication in 
there, most people that customize script surely know about sym links. 
At least this way it's easy for me to figure out if my exe are mine or 
someone else.

>>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.

But I don't see what's wrong with that.  Again the same could be 
occurring with a binary and it may take a certain time before someone 
figure it out.  The chance of that occuring are as unlikely for script 
that they are for binary because some people do test and find out that 
there's file being overwritten.  At least in that case only interested 
parties (the one with the script in use through rc-update) gets 
affected.  And not all other users who don't use that script while still 
using the 20-25 other scripts inside init.d

> <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.

I won't go and argue on how much time it takes.  It all depends on 
what's occuring and who's behind the screen.  What I'm saying thought is 
that right now, the way it's done it's more prone to broke a system and 
get the newbie running than helping him out while doing the reverse may 
not affect the experienced greatly while helping the newbie a lot.

> 
>>>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. 

Euh, I'm talking about gentoo here, people are interested to run the 
same init script, / partition for other distro at the same time?  But 
even then it probably would work as sym link are kernel/fs thing and not 
distro related.  Therefore the script would get executed as long as the 
target for the link exists.  Also the operation of moving the script 
inside a system.d folder is a gentoo thing and would only be doable from 
an ebuild script.  scripts coming out of tarball would be treated as if 
they were custom and therefore they won't be a symlink and gentoo would 
not overwrite them because of that. (if it's done like I mentionned 
previously)

> 
>>><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.
> 
> 

If you do emerge without looking into each file that got changes then 
your system may have been compromised.  I mean I can write a ebuild make 
a single syntax error inside a domain entry for the file, and buy that 
domain and get the file in there and you'll download it like most people 
once its approve and you'll get a buggy version which will compromise 
your system.  If your only put attention to what you put in /etc don't 
think you're system is ok.

Yannick Koehler

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

[Per Wigren]

How about having a "magic line" like:
###PROTECTED###
or something? Then emerge can overwrite the file if that line doesn't exist.. 

// Wigren

Monday 11 March 2002 19.02 skrev du:
> 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.
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@gentoo.org
> http://lists.gentoo.org/mailman/listinfo/gentoo-dev

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

[Craig M. Reece]

On Mon, Mar 11, 2002 at 07:45:32PM +0100, Per Wigren spoke thusly:
> How about having a "magic line" like:
> ###PROTECTED###
> or something? Then emerge can overwrite the file if that line doesn't exist.. 
>

I like this idea so long as I am still informed that there could have
been an update. I would still like to eyeball both scripts and see if I
want any changes.

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

[Yannick Koehler]

Per Wigren wrote:
> How about having a "magic line" like:
> ###PROTECTED###
> or something? Then emerge can overwrite the file if that line doesn't exist.. 
> 
> // Wigren
> 

I think it would be better to have a file outside the one which need to 
be protected that know/record which one has to be.  Let's say it's a 
config file and the end-user got a config-file from the web, if he just 
copy the file over the old one he will get f... the next emerge.  The 
current system is ok, the directory to protect are saved outside the 
config directory and you need to know where they are to mess with them. 
  They actually could get more flexible and have regexp/more granular 
selection in them thought.

Yannick Koehler

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

[Yannick Koehler]

Yannick Koehler wrote:
> 
> 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.
> 
> Yannick Koehler
> 
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@gentoo.org
> http://lists.gentoo.org/mailman/listinfo/gentoo-dev


Another point I have to make here is that there's a lot of files in 
there and MOST people won't change them.  Therefore the fact that each 
time someone play in there make 80-90% people force to merge many files 
is not really friendly.

Yannick Koehler

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

[Matt Beland]

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

On Mon, Mar 11, 2002 at 01:17:41PM -0500, Yannick Koehler wrote:
> Yannick Koehler wrote:
> >
> >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.
> >
> >Yannick Koehler
> >
> >_______________________________________________
> >gentoo-dev mailing list
> >gentoo-dev@gentoo.org
> >http://lists.gentoo.org/mailman/listinfo/gentoo-dev
> 
> 
> Another point I have to make here is that there's a lot of files in 
> there and MOST people won't change them.  Therefore the fact that each 
> time someone play in there make 80-90% people force to merge many files 
> is not really friendly.

Friendly, no, but it is proper behavior. Those files are critical to the 
proper operation of the system, and as such changes should be approached
with caution. Even if you as a Gentoo user are not making any customized
changes, it's a very good idea for you to be aware of changes in those 
files - that way, if you do emerge update --world and one of your daemons
breaks, you know if there've been any changes to the init script. It may 
not be a critical issue for you, but it will be for some.

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

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

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

[Yannick Koehler]

Matt Beland wrote:
> On Mon, Mar 11, 2002 at 01:17:41PM -0500, Yannick Koehler wrote:
> 
>>Yannick Koehler wrote:
>>
>>>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.
>>>
>>>Yannick Koehler
>>>
>>>_______________________________________________
>>>gentoo-dev mailing list
>>>gentoo-dev@gentoo.org
>>>http://lists.gentoo.org/mailman/listinfo/gentoo-dev
>>>
>>
>>Another point I have to make here is that there's a lot of files in 
>>there and MOST people won't change them.  Therefore the fact that each 
>>time someone play in there make 80-90% people force to merge many files 
>>is not really friendly.
>>
> 
> Friendly, no, but it is proper behavior. Those files are critical to the 
> proper operation of the system, and as such changes should be approached
> with caution. Even if you as a Gentoo user are not making any customized
> changes, it's a very good idea for you to be aware of changes in those 
> files - that way, if you do emerge update --world and one of your daemons
> breaks, you know if there've been any changes to the init script. It may 
> not be a critical issue for you, but it will be for some.
> 
> 

While I agree they are critical, I don't agree that they are more 
important than the program they control.  And that program is emerge 
automatically.  If the script work but the program failed after an 
emerge I think it is at the same critical level.

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.

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.

Yannick Koehler

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

[Ric Mesier]

Yannick,
	I appreciate your argument, but you can't equate a start-up script with
a binary. Yes, the binary is critical but it isn't likely to be
custom-altered like a start-up script might be. If I emerge package, I
expect the binaries to be altered. If I created a customer rc script,
then I want to be the one to clobber it, not have the emerge clobber it.
	This whole argument may well be irrelevant anyway. If you want to have
the scripts clobbered, then feel free to export CONFIG_PROTECT="". It
seems to be very nicely flexible in this fashion -- more of the genius
of the portage system.

Ric


On Mon, 2002-03-11 at 14:32, Yannick Koehler wrote:

> 
> 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 suspect your argument falls down here. New users more than likely
haven't altered any of the scripts there and as a result, they may be
able to unprotect the system when they do an emerge. 

Bottom line is, it seems to be up to the individual user.

Ric

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

[Yannick Koehler]

Ric Mesier wrote:
> Yannick,
> 	I appreciate your argument, but you can't equate a start-up script with
> a binary. Yes, the binary is critical but it isn't likely to be
> custom-altered like a start-up script might be. If I emerge package, I
> expect the binaries to be altered. If I created a customer rc script,
> then I want to be the one to clobber it, not have the emerge clobber it.
> 	This whole argument may well be irrelevant anyway. If you want to have
> the scripts clobbered, then feel free to export CONFIG_PROTECT="". It
> seems to be very nicely flexible in this fashion -- more of the genius
> of the portage system.
> 
> Ric
> 

Actually what I was looking for is a way to exclude /etc/init.d forever. 
  But keeping the protection on /etc.

Yannick Koehler

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

[Defresne Sylvain]

* Yannick Koehler (yannick.koehler@colubris.com) wrote:
> Actually what I was looking for is a way to exclude /etc/init.d forever. 
>  But keeping the protection on /etc.

  Then export CONFIG_PROTECT_MASK="/etc/init.d" and then /etc/init.d will be
excluded from config file protection ! If you like it, you can add it to
/etc/make.conf ...

Bye
-- 
Keiichi

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

[Ian Smith]

Defresne Sylvain wrote:

>   Then export CONFIG_PROTECT_MASK="/etc/init.d" and then /etc/init.d will be
> excluded from config file protection ! If you like it, you can add it to
> /etc/make.conf ...
> 
> Bye
> 

Ah you've answered my post anyway!  Is this documented anywhere?  I 
think at least a blank entry in /etc/make.globals would be useful . . .

-- 
----------------------------------------------------------------------------
Ian Smith
----------------------------------------------------------------------------

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

[Defresne Sylvain]

* Ian Smith (ian.c.smith@btinternet.com) wrote:
> Ah you've answered my post anyway!  Is this documented anywhere?  I 
> think at least a blank entry in /etc/make.globals would be useful . . .

  Don't know if this is in some doc ... Found it while reading the source
of portage ... I'm also in favor of adding this to /etc/make.globals:

# Directories to be excluded from config protection
CONFIG_PROTECT_MASK=""

Bye
-- 
Keiichi

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

[Martin Schlemmer]

On Tue, 2002-03-12 at 00:42, Ian Smith wrote:
> Defresne Sylvain wrote:
> 
> >   Then export CONFIG_PROTECT_MASK="/etc/init.d" and then /etc/init.d will be
> > excluded from config file protection ! If you like it, you can add it to
> > /etc/make.conf ...
> > 
> > Bye
> > 
> 
> Ah you've answered my post anyway!  Is this documented anywhere?  I 
> think at least a blank entry in /etc/make.globals would be useful . . .

nosferatu init.d # emerge

 * Regenerating GNU info directory index...
 * Processed 73 info files.
 * IMPORTANT: 14 config files in /etc need updating.
 * Type emerge --help config to learn how to update config files.

nosferatu init.d # emerge --help config

Config file management support (preliminary)

Portage has a special feature called "config file protection".  The
purpose of
this feature is to prevent new package installs from clobbering existig
configuration files.  By default, config file protection is turned on
for /etc
and the KDE configuration dirs; more may be added in the future.

When Portage installs a file into a protected directory tree like /etc,
any
existing files will not be overwritten.  If a file of the same name
already
exists, Portage will change the name of the to-be- installed file from
'foo' to
'._cfg0000_foo'.  If '._cfg0000_foo' already exists, this name becomes
'._cfg0001_foo', etc.  In this way, existing files are not overwritten,
allowing the administrator to manually merge the new config files and
avoid any
unexpected changes.

In addition to protecting overwritten files, Portage will not delete any
files
from a protected directory when a package is unmerged.  While this may
be a
little bit untidy, it does prevent potentially valuable config files
from being
deleted, which is of paramount importance.

Protected directories are set using the CONFIG_PROTECT variable,
normally
defined in /etc/make.globals.  Directory exceptions to the
CONFIG_PROTECTed
directories can be specified using the CONFIG_PROTECT_MASK variable.  To
find
files that need to be updated in /etc, type:

# find /etc -iname '._cfg????_*'

You can disable this feature by setting CONFIG_PROTECT="" in
/etc/make.conf.
Then, Portage will mercilessly auto-update your config files. 
Alternatively,
you can leave Config File Protection on but tell Portage that it can
overwrite
files in certain specific /etc subdirectories.  For example, if you
wanted
Portage to automatically update your rc scripts and your wget
configuration,
but didn't want any other changes made without your explicit approval,
you'd
add this to /etc/make.conf:

CONFIG_PROTECT_MASK="/etc/wget /etc/rc.d"

*Look Here ^^ 
==============

> 
> -- 
> ----------------------------------------------------------------------------
> Ian Smith
> ----------------------------------------------------------------------------
> 
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@gentoo.org
> http://lists.gentoo.org/mailman/listinfo/gentoo-dev
-- 

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

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

[Ian Smith]

Martin Schlemmer wrote:

> 
> nosferatu init.d # emerge --help config
> 


Oh crap, I thought it sounded familiar!  Thing is, I used to see that 
all the time until I started using etc-update . . .

Looks like Gentoo is starting to make me as lazy as Debian did ;)

-- 
----------------------------------------------------------------------------
Ian Smith
----------------------------------------------------------------------------

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

[Yannick Koehler]

Defresne Sylvain wrote:
> * Yannick Koehler (yannick.koehler@colubris.com) wrote:
> 
>>Actually what I was looking for is a way to exclude /etc/init.d forever. 
>> But keeping the protection on /etc.
>>
> 
>   Then export CONFIG_PROTECT_MASK="/etc/init.d" and then /etc/init.d will be
> excluded from config file protection ! If you like it, you can add it to
> /etc/make.conf ...
> 
> Bye
> 

Thanks,

Someone already answered me on that.

Yannick Koehelr

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

[Ian Smith]

Yannick Koehler wrote:

> 
> Actually what I was looking for is a way to exclude /etc/init.d forever. 
>  But keeping the protection on /etc.

. . . like include & exclude in tar etc.  Is it not worth another env 
var (CONFIG_EXPOSE or suchlike)?

-- 
----------------------------------------------------------------------------
Ian Smith
----------------------------------------------------------------------------

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

[Ian Smith]

Ric Mesier wrote:
> Yannick,
> 	I appreciate your argument, but you can't equate a start-up script with
> a binary. Yes, the binary is critical but it isn't likely to be
> custom-altered like a start-up script might be. If I emerge package, I
> expect the binaries to be altered. If I created a customer rc script,
> then I want to be the one to clobber it, not have the emerge clobber it.

You can equate them in the sense that they execute things, in fact the 
only sense in which they are config files is by virtue of them being 
under /etc !

A cynic might even suggest this is a circular argument . . .

-- 
----------------------------------------------------------------------------
Ian Smith
----------------------------------------------------------------------------

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

[Martin Schlemmer]

On Mon, 2002-03-11 at 21:32, Yannick Koehler wrote:
> Matt Beland wrote:
> > On Mon, Mar 11, 2002 at 01:17:41PM -0500, Yannick Koehler wrote:
> > 
> >>Yannick Koehler wrote:
> >>
> >>>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.
> >>>
> >>>Yannick Koehler
> >>>
> >>>_______________________________________________
> >>>gentoo-dev mailing list
> >>>gentoo-dev@gentoo.org
> >>>http://lists.gentoo.org/mailman/listinfo/gentoo-dev
> >>>
> >>
> >>Another point I have to make here is that there's a lot of files in 
> >>there and MOST people won't change them.  Therefore the fact that each 
> >>time someone play in there make 80-90% people force to merge many files 
> >>is not really friendly.
> >>
> > 
> > Friendly, no, but it is proper behavior. Those files are critical to the 
> > proper operation of the system, and as such changes should be approached
> > with caution. Even if you as a Gentoo user are not making any customized
> > changes, it's a very good idea for you to be aware of changes in those 
> > files - that way, if you do emerge update --world and one of your daemons
> > breaks, you know if there've been any changes to the init script. It may 
> > not be a critical issue for you, but it will be for some.
> > 
> > 
> 
> While I agree they are critical, I don't agree that they are more 
> important than the program they control.  And that program is emerge 
> automatically.  If the script work but the program failed after an 
> emerge I think it is at the same critical level.
> 
> 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.
> 
> 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 feel the same about this point.  Especially with scripts like
/etc/init.d/depscan.sh, /etc/init.d/runscript.sh and
/etc/init.d/functions.sh, not updating leaded to many problems, where
unable to boot after first time build was one of them.

In the last few baselayout releases, there was major feature additions,
rewrites, etc, making a slight diff glob, or not updating a great risk
for creating problems.

Just these should IMHO be updated realtime, and not placing a backup.

> Yannick Koehler
> 
> 
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@gentoo.org
> http://lists.gentoo.org/mailman/listinfo/gentoo-dev
-- 

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

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

[Matt Beland]

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

On Mon, Mar 11, 2002 at 02:32:24PM -0500, Yannick Koehler wrote:
> Matt Beland wrote:
> >On Mon, Mar 11, 2002 at 01:17:41PM -0500, Yannick Koehler wrote:
> >
> >>Yannick Koehler wrote:
> >>>  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.
> >>
> >>Another point I have to make here is that there's a lot of files in 
> >>there and MOST people won't change them.  Therefore the fact that each 
> >>time someone play in there make 80-90% people force to merge many files 
> >>is not really friendly.
> >
> >Friendly, no, but it is proper behavior. Those files are critical to the 
> >proper operation of the system, and as such changes should be approached
> >with caution. Even if you as a Gentoo user are not making any customized
> >changes, it's a very good idea for you to be aware of changes in those 
> >files - that way, if you do emerge update --world and one of your daemons
> >breaks, you know if there've been any changes to the init script. It may 
> >not be a critical issue for you, but it will be for some.
> 
> While I agree they are critical, I don't agree that they are more 
> important than the program they control.  And that program is emerge 
> automatically.  If the script work but the program failed after an 
> emerge I think it is at the same critical level.

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.

> 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.

> 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.

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

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

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

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

[Thilo Bangert]

Hi all,

it SOUNDS like some of you don't know about etc-update from the 
gentoolkit... check it out

-- 
regards
Thilo

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

[Joachim Blaabjerg]

On Mon, 2002-03-11 at 18:48, Yannick Koehler wrote:
<snip>

I might be stumbling in the dark here, but what if Portage stored all
the files that were installed in a protected directory in
somewhere/app-category/app/app-version/dir/file (or whatever), and did a
diff on those verbatim files that were installed, so the user can see
what has changed between the two original versions (the ones he hasn't
changed yet)? My biggest problem right now is that of diff'ing a file,
and spotting what changes I did, and what changes the package came
with...

Anyway, I'm really tired here. Please ignore this if it's really stupid,
or someone else mentioned it in the beginning of the thread ;)
 
-- 
Joachim Blaabjerg
styx@SuxOS.org
www.SuxOS.org

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

[Yannick Koehler]

Joachim Blaabjerg wrote:
> On Mon, 2002-03-11 at 18:48, Yannick Koehler wrote:
> <snip>
> 
> I might be stumbling in the dark here, but what if Portage stored all
> the files that were installed in a protected directory in
> somewhere/app-category/app/app-version/dir/file (or whatever), and did a
> diff on those verbatim files that were installed, so the user can see
> what has changed between the two original versions (the ones he hasn't
> changed yet)? My biggest problem right now is that of diff'ing a file,
> and spotting what changes I did, and what changes the package came
> with...
> 
> Anyway, I'm really tired here. Please ignore this if it's really stupid,
> or someone else mentioned it in the beginning of the thread ;)
>  
> 

I find that a little too expensive.  Maybe a good idea for config files 
thought.

Yannick Koehler

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

[Tod M. Neidt]

Hi!

On Mon, 2002-03-11 at 11:48, Yannick Koehler wrote:
> 
> 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)?

I suggest that you review 'emerge --help config'

Summary:  

Protected directories are set with CONFIG_PROTECT= in /etc/make.conf
(global setting is in /etc/make.globals).

To override for a particular directory or subdirectory use
CONFIG_PROTECT_MASK=

For example,

CONFIG_PROTECT="/etc"

to protect everything under /etc from getting automagically updated.

CONFIG_PROTECT_MASK="/etc/init.d"

if you want to allow stuff under /etc/init.d to be updated without
review.


Essentially all the functionality that you mention already exists. 
Also, as has already been mentioned, etc-update is your friend.

Hope that helps,

tod

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

[Yannick Koehler]

Tod M. Neidt wrote:
> Hi!
> 
> On Mon, 2002-03-11 at 11:48, Yannick Koehler wrote:
> 
>>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)?
>>
> 
> I suggest that you review 'emerge --help config'
> 
> Summary:  
> 
> Protected directories are set with CONFIG_PROTECT= in /etc/make.conf
> (global setting is in /etc/make.globals).
> 
> To override for a particular directory or subdirectory use
> CONFIG_PROTECT_MASK=
> 
> For example,
> 
> CONFIG_PROTECT="/etc"
> 
> to protect everything under /etc from getting automagically updated.
> 
> CONFIG_PROTECT_MASK="/etc/init.d"
> 
> if you want to allow stuff under /etc/init.d to be updated without
> review.
> 
> 
> Essentially all the functionality that you mention already exists. 
> Also, as has already been mentioned, etc-update is your friend.
> 
> Hope that helps,
> 
> tod
> 
> 
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@gentoo.org
> http://lists.gentoo.org/mailman/listinfo/gentoo-dev
> 

Great,

at last, I have the answer I was looking for.  I have not seen 
etc-update because it's a package (gentoolkit) I didn't install because 
I didn't need it.

Thanks
Yannick Koehler

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

[Bob Phan]

On Mon, 11 Mar 2002, Yannick Koehler wrote:

> Great,
> 
> at last, I have the answer I was looking for.  I have not seen 
> etc-update because it's a package (gentoolkit) I didn't install because 
> I didn't need it.

That brings up something interesting.  Shouldn't gentoolkit be part of
the system profile?  I can't think of a single reason for someone to
_not_ have it installed.  etc-update and qpkg should be installed just
as readily as emerge.  A good 25% of the questions on this list have
resulted in, "emerge gentoolkit".  Any thoughts?

-- 
/*
 * Bob Phan <bob@endlressrecursion.net,rphan@nrgn.com>
 * Computational Chemistry Informatics
 * Neurogen Corporation
 * (203)488-8201 x4645
 *
 * To understand recursion, you must first understand recursion.
 */

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

[Craig M. Reece]

On Mon, Mar 11, 2002 at 04:26:20PM +0000, Bob Phan spoke thusly:
> On Mon, 11 Mar 2002, Yannick Koehler wrote:
> 
> > Great,
> > 
> > at last, I have the answer I was looking for.  I have not seen 
> > etc-update because it's a package (gentoolkit) I didn't install because 
> > I didn't need it.
> 
> That brings up something interesting.  Shouldn't gentoolkit be part of
> the system profile?  I can't think of a single reason for someone to
> _not_ have it installed.  etc-update and qpkg should be installed just
> as readily as emerge.  A good 25% of the questions on this list have
> resulted in, "emerge gentoolkit".  Any thoughts?
>

Perhaps a subset comprising qpkg and etc-update should be made into a
different package. If I recall correctly, emerge --pretend gentoolkit
showed that I needed a bunch of X etc dependancies (full memory
recall eludes me at the moment) which is not desired for a default
minimalist setup.

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

[Bob Phan]

On Mon, 11 Mar 2002, Craig M. Reece wrote:

> Perhaps a subset comprising qpkg and etc-update should be made into a
> different package. If I recall correctly, emerge --pretend gentoolkit
> showed that I needed a bunch of X etc dependancies (full memory
> recall eludes me at the moment) which is not desired for a default
> minimalist setup.

I agree with the separate package do to all the other scripts in there
that are not as useful/stable.  But, from the ebuild file, it only depends
on:

RDEPEND=">=dev-lang/python-2.0
    >=sys-devel/perl-5.6"

-- 
/*
 * Bob Phan <bob@endlressrecursion.net,rphan@nrgn.com>
 * Computational Chemistry Informatics
 * Neurogen Corporation
 * (203)488-8201 x4645
 *
 * To understand recursion, you must first understand recursion.
 */

Re: [gentoo-dev] /etc/init.d the real question!?

[Corvus Corax]

This topic goes quite long now doesnt it?

Is it realle the question if /etc/init.d should be masked or not?

Since every user is able to change this himself i`d like to say the real 
question is:
What initial knowledge requirements should a newbee GENTOO USER have?

Here comes a list, what i think a gentoo user needs to know till now to 
install a new gentoo onto his mashine:

general LINUX knowledge	-- the user should have used Linux before
knowledge of bash 		-- you need it to install at least base-layout
knowledge of nano / vi		-- without knowing how to use an editor he is lost <g>
knowledge how to setup 
   either LAN
    or     PPPd / dialin
    or     ADSL /cable / ...		-- without the user wont get a single ebuild
				    installed
knowledge how to configure
  the kernel			-- imagine one who has never made the
				   make menuconfig && make dep && make clean && make bzImage &&
				   make modules && make modules_install &&
				   cp arch/i386/boot/bzImage /boot ...  --->completely LOST!
knowledge how to setup
his preferred boot-loader		-- which does he want? grub? lilo?, ... but you
				   need one.

knowledge how to compile	-- should know about the usual ./configure &&
				    make && make install series or not? 

knowledge of the portage sys	-- a user who trys to install gentoo without
				   having read the docs on gentoo.org? ooops <g>

to be continued...
Hmmm don't you think a user who got thus far doesnt know how the init process 
works, and what he has to do with the ._cfg00?_* files ? especially since 
emerge prompts for them after every installed ebuild?


my opinion, as an gentoo user --- Corvus V Corax

Re: [gentoo-dev] /etc/init.d the real question!?

[Yannick Koehler]

Corvus Corax wrote:
> This topic goes quite long now doesnt it?
> 
> Is it realle the question if /etc/init.d should be masked or not?
> 
> Since every user is able to change this himself i`d like to say the real 
> question is:
> What initial knowledge requirements should a newbee GENTOO USER have?
> 
> Here comes a list, what i think a gentoo user needs to know till now to 
> install a new gentoo onto his mashine:
> 
> general LINUX knowledge	-- the user should have used Linux before
> knowledge of bash 		-- you need it to install at least base-layout
> knowledge of nano / vi		-- without knowing how to use an editor he is lost <g>
> knowledge how to setup 
>    either LAN
>     or     PPPd / dialin
>     or     ADSL /cable / ...		-- without the user wont get a single ebuild
> 				    installed
> knowledge how to configure
>   the kernel			-- imagine one who has never made the
> 				   make menuconfig && make dep && make clean && make bzImage &&
> 				   make modules && make modules_install &&
> 				   cp arch/i386/boot/bzImage /boot ...  --->completely LOST!
> knowledge how to setup
> his preferred boot-loader		-- which does he want? grub? lilo?, ... but you
> 				   need one.
> 
> knowledge how to compile	-- should know about the usual ./configure &&
> 				    make && make install series or not? 
> 
> knowledge of the portage sys	-- a user who trys to install gentoo without
> 				   having read the docs on gentoo.org? ooops <g>
> 
> to be continued...
> Hmmm don't you think a user who got thus far doesnt know how the init process 
> works, and what he has to do with the ._cfg00?_* files ? especially since 
> emerge prompts for them after every installed ebuild?
> 
> 
> my opinion, as an gentoo user --- Corvus V Corax
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@gentoo.org
> http://lists.gentoo.org/mailman/listinfo/gentoo-dev
> 

Like I mentionned before, that's probably what gentoo require today. 
Once you have a distro on CD where it can process with some of those 
steps automatically you'll still get new users just because of the 
portage way of doing things.

And with the documentation available on the web site, someone may get to 
install gentoo without that much knowledge.

Yannick Koehler

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

[Craig M. Reece]

On Mon, Mar 11, 2002 at 04:42:42PM +0000, Bob Phan spoke thusly:
> On Mon, 11 Mar 2002, Craig M. Reece wrote:
> 
> > Perhaps a subset comprising qpkg and etc-update should be made into a
> > different package. If I recall correctly, emerge --pretend gentoolkit
> > showed that I needed a bunch of X etc dependancies (full memory
> > recall eludes me at the moment) which is not desired for a default
> > minimalist setup.
> 
> I agree with the separate package do to all the other scripts in there
> that are not as useful/stable.  But, from the ebuild file, it only depends
> on:
> 
> RDEPEND=">=dev-lang/python-2.0
>     >=sys-devel/perl-5.6"
>

Doh! I should have guessed that my loaded up USE variable added all the
extra weight in my --pretend output.