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 |