Gentoo Archives: gentoo-dev

From: Matt Beland <matt@××××××××××××××.org>
To: gentoo-dev@g.o
Subject: Re: [gentoo-dev] /etc/init.d
Date: Mon, 11 Mar 2002 13:59:53
Message-Id: 20020311195636.GE28735@rearviewmirror.org
In Reply to: Re: [gentoo-dev] /etc/init.d by Yannick Koehler
1 On Mon, Mar 11, 2002 at 02:32:24PM -0500, Yannick Koehler wrote:
2 > Matt Beland wrote:
3 > >On Mon, Mar 11, 2002 at 01:17:41PM -0500, Yannick Koehler wrote:
4 > >
5 > >>Yannick Koehler wrote:
6 > >>> not sure for anyone else but is init.d really need to be protected?
7 > >>>I mean does someone really change files in that directory (other than
8 > >>>adding or removing)?
9 > >>>
10 > >>> That dir should always get merged. It would also get really nice of
11 > >>>the portage could detect that no changes has been made to the file since
12 > >>>its installation and therefore merge it without any issues.
13 > >>>
14 > >>> Like if the protected config file's time were saved in a temp files
15 > >>>that portage would look into before merging to see if the date has or
16 > >>>not change since the last install.
17 > >>
18 > >>Another point I have to make here is that there's a lot of files in
19 > >>there and MOST people won't change them. Therefore the fact that each
20 > >>time someone play in there make 80-90% people force to merge many files
21 > >>is not really friendly.
22 > >
23 > >Friendly, no, but it is proper behavior. Those files are critical to the
24 > >proper operation of the system, and as such changes should be approached
25 > >with caution. Even if you as a Gentoo user are not making any customized
26 > >changes, it's a very good idea for you to be aware of changes in those
27 > >files - that way, if you do emerge update --world and one of your daemons
28 > >breaks, you know if there've been any changes to the init script. It may
29 > >not be a critical issue for you, but it will be for some.
30 >
31 > While I agree they are critical, I don't agree that they are more
32 > important than the program they control. And that program is emerge
33 > automatically. If the script work but the program failed after an
34 > emerge I think it is at the same critical level.
35
36 They are not more important, than the binaries, but they are far more likely
37 to have been modified by the end user. If the end user has modified the
38 binary, then they almost certainly are not using the ebuild. However, if all
39 I want/need to do is modify the initscript, then I'm not going to go to the
40 added hassle of manually tracking the program just because I use a different
41 init from that provided by the ebuild.
42
43 > Therefore I think they should be treated the same. Now they are treated
44 > as config file and require end-users intervention when I don't see a
45 > reason for most end-user. Like programs, some users will modify their
46 > program by using personnaly modified source tree and those would know
47 > not to put the binary or merge those package.
48
49 They are treated as a config file because they are a config file. They control
50 how the binaries are started, how they're stopped, and how they're tracked
51 while running. The current behavior is the proper behavior.
52
53 > Actually I think it's even worse treating those files as config.
54 > Because new users, the one that you always want to get in a distro may
55 > be running pretty old script as they may not be aware on how to do the
56 > merge step manually.
57
58 I understand the point behind being newbie-friendly, and the arguments for
59 making something "easier for new users", but I have to disagree in this case.
60 You're advocating making the system easier for a new user while making life
61 more difficult for an advanced user. Quite frankly, that's why many of us
62 *moved* to Gentoo over RedHat or one of the other distributions - they make
63 life easier for new users at the expense of some of the innate power and
64 flexibility of Unix.
65
66 --
67 Matt Beland
68 matt@××××××××××××××.org
69 http://www.rearviewmirror.org

Replies

Subject Author
Re: [gentoo-dev] /etc/init.d Yannick Koehler <yannick.koehler@××××××××.com>