1 |
Matt Beland wrote: |
2 |
> On Mon, Mar 11, 2002 at 01:16:45PM -0500, Yannick Koehler wrote: |
3 |
> |
4 |
>>Craig M. Reece wrote: |
5 |
>> |
6 |
>>>On Mon, Mar 11, 2002 at 12:48:08PM -0500, Yannick Koehler spoke thusly: |
7 |
>>> |
8 |
>>> |
9 |
>>>>Guys, |
10 |
>>>> |
11 |
>>>> not sure for anyone else but is init.d really need to be protected? |
12 |
>>>> I mean does someone really change files in that directory (other |
13 |
>>>> than adding or removing)? |
14 |
>>>> |
15 |
>>>> That dir should always get merged. It would also get really nice of |
16 |
>>>> the portage could detect that no changes has been made to the file |
17 |
>>>> since its installation and therefore merge it without any issues. |
18 |
>>>> |
19 |
>>>> Like if the protected config file's time were saved in a temp files |
20 |
>>>> that portage would look into before merging to see if the date has |
21 |
>>>> or not change since the last install. |
22 |
>>>> |
23 |
>>>> |
24 |
>>>> |
25 |
>>>Yes it needs to be protected. I, for instance, have my own version of |
26 |
>>>pcmcia in there that I don't want stepped on. Also, I have a couple of |
27 |
>>>other custom scripts for things not in portage yet; and when they are in |
28 |
>>>portage, I want to be able to compare the differences before using one |
29 |
>>>or the other. |
30 |
>>> |
31 |
>>The reasoning I have is that those are scripts, and not config files. |
32 |
>>If ... instead of modifying pcmcia script for example like you |
33 |
>>mentionned you were to cp pcmcia pcmcia.modif and rc-update add |
34 |
>>pcmcia.modif default / rc-update del pcmcia default the system would |
35 |
>>work and you'll never get concerned about the new pcmcia scripts. |
36 |
>> |
37 |
> |
38 |
> They are sometimes both scripts and config files. Personally, I like the |
39 |
> layout of the Gentoo initscripts, particularly with regard to the "local" |
40 |
> script and the ability to start "simple" daemons and scripts with a config |
41 |
> file. However, many of the scripts we add to the init.d directory are not |
42 |
> custom-written for Gentoo, they're written for Linux in general. They |
43 |
> include the necessary config settings in the init file itself. And those |
44 |
> should not be clobbered. |
45 |
> |
46 |
|
47 |
While I understand that by having seen some of those scripts in the |
48 |
past, I don't see a reason not to either do work by removing those |
49 |
'config' part and moving them to a /etc/ file and then committing a |
50 |
patch into gentoo or the original package owner. I'm pretty sure doing |
51 |
so wouldn't be considered gentoo either. I've seen some distro doing |
52 |
that inside most of their init scripts in order to ensure no one play |
53 |
with them directely and kind of filtering the dangerous settings from |
54 |
the config file (always by warning the end-user thought through a log or |
55 |
something like that). |
56 |
|
57 |
>>If you changes those scripts maybe it's even better to tell people about |
58 |
>>your changes as they may get implemented such that the script itself |
59 |
>>read a config files (like net.eth0) so that other people can re-use your |
60 |
>>modifications. |
61 |
>> |
62 |
> |
63 |
> That's fine for things like the tweaked pcmcia script - but what if the |
64 |
> tweaks are in order to permit a specific driver to work properly? Those |
65 |
> changes should not be in the default initscript, they should at most be |
66 |
> provided as a commented-out section - which, again, would require user |
67 |
> intervention to create the required "tweaked" script. |
68 |
|
69 |
I don't agree here. If you have script that make a piece of hardware |
70 |
work they should get committed inside Gentoo. Otherwise other people |
71 |
that have the same issues won't be able to make it work either. If it's |
72 |
for a specific hardware combination then why making all other users |
73 |
spend their time diff/mv files while you'll be the only one with that |
74 |
problem? |
75 |
|
76 |
Also having something like I mentionned called user.d where you could |
77 |
put your own script file would be resolving that. Maybe even better |
78 |
would be to have gentoo write scripts by default to system.d and have |
79 |
symlink inside init.d so that if it attempt to copy a script inside |
80 |
init.d and see that it's not a link to a system.d files then it doesn't |
81 |
override it and warn instead. The whole idea could also be used for the |
82 |
/etc folder completely. |
83 |
|
84 |
> It wouldn't solve the problem for custom scripts. Suppose (as an example) |
85 |
> that I have installed OpenSSH by compiling it from source, then later |
86 |
> I emerge the ssh ebuild. I would have installed an initscript already, |
87 |
> I would call it 'sshd' by default. Before I blindly replace it with the |
88 |
> Gentoo initscript, I would want to examine it and see how it did things. |
89 |
> |
90 |
|
91 |
|
92 |
see above |
93 |
|
94 |
>>And maybe a user's scripts directory should exists, something like |
95 |
>>/etc/user.d where people can move their custom scripts and the stuff |
96 |
>>behind rc-update would got here first and if it doesn't found the script |
97 |
>>then to /etc/init.d. |
98 |
>> |
99 |
> |
100 |
> While I don't agree with everything that "the standard linux" build does, |
101 |
> particularly as defined in the LSB project, I don't think we should be |
102 |
> creating new directories within /etc/ just to make things a little more |
103 |
> convenient. Especiually when that convenience comes with a price in the |
104 |
> form of an increased risk of system breakage. |
105 |
|
106 |
Actually I think the opposite. Convenience for me is really important. |
107 |
The less I have to do the more I'm happy and can do something else. |
108 |
That's why I'm complaining at the first place. I've merge a couple of |
109 |
time baselayout and while this package shouldn't be updated frequentely |
110 |
IMHO it shouldn't be kept idle either if it can still be enhanced. |
111 |
Therefore I think to make the thing more convenient and less annyoing we |
112 |
should enhance it a little more. |
113 |
|
114 |
Yannick Koehler |