1 |
I now have my solution so I'm mostly arguing just for the fun of it now ;-) |
2 |
|
3 |
|
4 |
Matt Beland wrote: |
5 |
> On Mon, Mar 11, 2002 at 11:10:14PM +0200, Martin Schlemmer wrote: |
6 |
> |
7 |
>>On Mon, 2002-03-11 at 22:44, Yannick Koehler wrote: |
8 |
>> |
9 |
>>>Matt Beland wrote: |
10 |
>>> |
11 |
>>>><snip> |
12 |
>>>>They are sometimes both scripts and config files. Personally, I like the |
13 |
>>>>layout of the Gentoo initscripts, particularly with regard to the "local" |
14 |
>>>>script and the ability to start "simple" daemons and scripts with a config |
15 |
>>>>file. However, many of the scripts we add to the init.d directory are not |
16 |
>>>>custom-written for Gentoo, they're written for Linux in general. They |
17 |
>>>>include the necessary config settings in the init file itself. And those |
18 |
>>>>should not be clobbered. |
19 |
>>>> |
20 |
>>>> |
21 |
>>>While I understand that by having seen some of those scripts in the |
22 |
>>>past, I don't see a reason not to either do work by removing those |
23 |
>>>'config' part and moving them to a /etc/ file and then committing a |
24 |
>>>patch into gentoo or the original package owner. I'm pretty sure doing |
25 |
>>>so wouldn't be considered gentoo either. I've seen some distro doing |
26 |
>>>that inside most of their init scripts in order to ensure no one play |
27 |
>>>with them directely and kind of filtering the dangerous settings from |
28 |
>>>the config file (always by warning the end-user thought through a log or |
29 |
>>>something like that). |
30 |
>>> |
31 |
> |
32 |
> But we're not talking about Gentoo init scripts, necessarily. If the script was |
33 |
> installed by some program, and there's no build for it nor is there any real |
34 |
> interest in creating an ebuild for it, then why create a config file and all of |
35 |
> this extra effort you're proposing for what may be a very simple script. If |
36 |
> the program is not part of an ebuild, you might not notice emerge clobbering |
37 |
> your script thanks to an unfortunate collision in the script name. |
38 |
> |
39 |
|
40 |
The same occurs if I create a software and I give it a name and inside a |
41 |
package there's a binary with the name which obviously will get over my |
42 |
/usr/bin file. The chance are probably the same. If you write binary |
43 |
you'll have this problem, if you write script, well... you'll have the |
44 |
problem too. Try to compare both ... believe it or not I may write 1-2 |
45 |
utilities for my testing per week and name clashing can occurs as I'm |
46 |
not the only one working on the cvs repository we use. The trick, well, |
47 |
I move my stuff into my own folder and I create sym links, the same |
48 |
trick can safely be done in /etc/init.d. I don't see a complication in |
49 |
there, most people that customize script surely know about sym links. |
50 |
At least this way it's easy for me to figure out if my exe are mine or |
51 |
someone else. |
52 |
|
53 |
>>Once again ... if you have everthing latest, you should not need to edit |
54 |
>>a file in /etc/init.d/ . All the config settings is in /etc/conf.d/ . |
55 |
>>This should anyhow go for most users who do not have a unusual setup. |
56 |
>> |
57 |
> |
58 |
> I am not necessarily referring to Gentoo programs or scripts. I am aware that |
59 |
> the Gentoo init scripts, as designed, do not require any protection. The issue |
60 |
> is init scripts that are created for some other daemon not installed as part |
61 |
> of Gentoo potentially being clobbered by a Gentoo-installed script. |
62 |
|
63 |
But I don't see what's wrong with that. Again the same could be |
64 |
occurring with a binary and it may take a certain time before someone |
65 |
figure it out. The chance of that occuring are as unlikely for script |
66 |
that they are for binary because some people do test and find out that |
67 |
there's file being overwritten. At least in that case only interested |
68 |
parties (the one with the script in use through rc-update) gets |
69 |
affected. And not all other users who don't use that script while still |
70 |
using the 20-25 other scripts inside init.d |
71 |
|
72 |
> <snip> |
73 |
> |
74 |
>>>>That's fine for things like the tweaked pcmcia script - but what if the |
75 |
>>>>tweaks are in order to permit a specific driver to work properly? Those |
76 |
>>>>changes should not be in the default initscript, they should at most be |
77 |
>>>>provided as a commented-out section - which, again, would require user |
78 |
>>>>intervention to create the required "tweaked" script. |
79 |
>>>> |
80 |
>>>I don't agree here. If you have script that make a piece of hardware |
81 |
>>>work they should get committed inside Gentoo. Otherwise other people |
82 |
>>>that have the same issues won't be able to make it work either. If it's |
83 |
>>> for a specific hardware combination then why making all other users |
84 |
>>>spend their time diff/mv files while you'll be the only one with that |
85 |
>>>problem? |
86 |
>>> |
87 |
> |
88 |
> Because this is *one example* of an issue which creates problems. It is not |
89 |
> an exclusive problem where this is the only time it would create a problem. |
90 |
> |
91 |
> I updated my workstation and two test Gentoo boxes last night, including |
92 |
> baselayout changes. It took an extra minute maximum per box to look through |
93 |
> the scripts, identify the two that might be a problem, and update the rest. |
94 |
> I hardly think that's a terrible burden to assume. |
95 |
|
96 |
I won't go and argue on how much time it takes. It all depends on |
97 |
what's occuring and who's behind the screen. What I'm saying thought is |
98 |
that right now, the way it's done it's more prone to broke a system and |
99 |
get the newbie running than helping him out while doing the reverse may |
100 |
not affect the experienced greatly while helping the newbie a lot. |
101 |
|
102 |
> |
103 |
>>>Also having something like I mentionned called user.d where you could |
104 |
>>>put your own script file would be resolving that. Maybe even better |
105 |
>>>would be to have gentoo write scripts by default to system.d and have |
106 |
>>>symlink inside init.d so that if it attempt to copy a script inside |
107 |
>>>init.d and see that it's not a link to a system.d files then it doesn't |
108 |
>>>override it and warn instead. The whole idea could also be used for the |
109 |
>>>/etc folder completely. |
110 |
>>> |
111 |
> |
112 |
> It would resolve the problem but break compatability with every other Linux |
113 |
> distribution. |
114 |
|
115 |
Euh, I'm talking about gentoo here, people are interested to run the |
116 |
same init script, / partition for other distro at the same time? But |
117 |
even then it probably would work as sym link are kernel/fs thing and not |
118 |
distro related. Therefore the script would get executed as long as the |
119 |
target for the link exists. Also the operation of moving the script |
120 |
inside a system.d folder is a gentoo thing and would only be doable from |
121 |
an ebuild script. scripts coming out of tarball would be treated as if |
122 |
they were custom and therefore they won't be a symlink and gentoo would |
123 |
not overwrite them because of that. (if it's done like I mentionned |
124 |
previously) |
125 |
|
126 |
> |
127 |
>>><snip> |
128 |
>>>Actually I think the opposite. Convenience for me is really important. |
129 |
>>> The less I have to do the more I'm happy and can do something else. |
130 |
>>>That's why I'm complaining at the first place. I've merge a couple of |
131 |
>>>time baselayout and while this package shouldn't be updated frequentely |
132 |
>>>IMHO it shouldn't be kept idle either if it can still be enhanced. |
133 |
>>>Therefore I think to make the thing more convenient and less annyoing we |
134 |
>>>should enhance it a little more. |
135 |
>>> |
136 |
> |
137 |
> Quite franky, convenience should never be given priority in cases like this. |
138 |
> System updates should be as convenient as possible *without compromising the |
139 |
> system*. We're not talking about making it easier to read your email, we're |
140 |
> talking about modifying a core system directory with files that are critical |
141 |
> to the proper operation of the system. Convenience is and should always in |
142 |
> such cases be secondary to stability and security. |
143 |
> |
144 |
> |
145 |
|
146 |
If you do emerge without looking into each file that got changes then |
147 |
your system may have been compromised. I mean I can write a ebuild make |
148 |
a single syntax error inside a domain entry for the file, and buy that |
149 |
domain and get the file in there and you'll download it like most people |
150 |
once its approve and you'll get a buggy version which will compromise |
151 |
your system. If your only put attention to what you put in /etc don't |
152 |
think you're system is ok. |
153 |
|
154 |
Yannick Koehler |