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