1 |
On Mon, Mar 11, 2002 at 11:10:14PM +0200, Martin Schlemmer wrote: |
2 |
> On Mon, 2002-03-11 at 22:44, Yannick Koehler wrote: |
3 |
> > Matt Beland wrote: |
4 |
> > > <snip> |
5 |
> > > They are sometimes both scripts and config files. Personally, I like the |
6 |
> > > layout of the Gentoo initscripts, particularly with regard to the "local" |
7 |
> > > script and the ability to start "simple" daemons and scripts with a config |
8 |
> > > file. However, many of the scripts we add to the init.d directory are not |
9 |
> > > custom-written for Gentoo, they're written for Linux in general. They |
10 |
> > > include the necessary config settings in the init file itself. And those |
11 |
> > > should not be clobbered. |
12 |
> > > |
13 |
> > |
14 |
> > While I understand that by having seen some of those scripts in the |
15 |
> > past, I don't see a reason not to either do work by removing those |
16 |
> > 'config' part and moving them to a /etc/ file and then committing a |
17 |
> > patch into gentoo or the original package owner. I'm pretty sure doing |
18 |
> > so wouldn't be considered gentoo either. I've seen some distro doing |
19 |
> > that inside most of their init scripts in order to ensure no one play |
20 |
> > with them directely and kind of filtering the dangerous settings from |
21 |
> > the config file (always by warning the end-user thought through a log or |
22 |
> > something like that). |
23 |
> > |
24 |
|
25 |
But we're not talking about Gentoo init scripts, necessarily. If the script was |
26 |
installed by some program, and there's no build for it nor is there any real |
27 |
interest in creating an ebuild for it, then why create a config file and all of |
28 |
this extra effort you're proposing for what may be a very simple script. If |
29 |
the program is not part of an ebuild, you might not notice emerge clobbering |
30 |
your script thanks to an unfortunate collision in the script name. |
31 |
|
32 |
> Once again ... if you have everthing latest, you should not need to edit |
33 |
> a file in /etc/init.d/ . All the config settings is in /etc/conf.d/ . |
34 |
> This should anyhow go for most users who do not have a unusual setup. |
35 |
|
36 |
I am not necessarily referring to Gentoo programs or scripts. I am aware that |
37 |
the Gentoo init scripts, as designed, do not require any protection. The issue |
38 |
is init scripts that are created for some other daemon not installed as part |
39 |
of Gentoo potentially being clobbered by a Gentoo-installed script. |
40 |
|
41 |
<snip> |
42 |
> > > That's fine for things like the tweaked pcmcia script - but what if the |
43 |
> > > tweaks are in order to permit a specific driver to work properly? Those |
44 |
> > > changes should not be in the default initscript, they should at most be |
45 |
> > > provided as a commented-out section - which, again, would require user |
46 |
> > > intervention to create the required "tweaked" script. |
47 |
> > |
48 |
> > I don't agree here. If you have script that make a piece of hardware |
49 |
> > work they should get committed inside Gentoo. Otherwise other people |
50 |
> > that have the same issues won't be able to make it work either. If it's |
51 |
> > for a specific hardware combination then why making all other users |
52 |
> > spend their time diff/mv files while you'll be the only one with that |
53 |
> > problem? |
54 |
|
55 |
Because this is *one example* of an issue which creates problems. It is not |
56 |
an exclusive problem where this is the only time it would create a problem. |
57 |
|
58 |
I updated my workstation and two test Gentoo boxes last night, including |
59 |
baselayout changes. It took an extra minute maximum per box to look through |
60 |
the scripts, identify the two that might be a problem, and update the rest. |
61 |
I hardly think that's a terrible burden to assume. |
62 |
|
63 |
> > Also having something like I mentionned called user.d where you could |
64 |
> > put your own script file would be resolving that. Maybe even better |
65 |
> > would be to have gentoo write scripts by default to system.d and have |
66 |
> > symlink inside init.d so that if it attempt to copy a script inside |
67 |
> > init.d and see that it's not a link to a system.d files then it doesn't |
68 |
> > override it and warn instead. The whole idea could also be used for the |
69 |
> > /etc folder completely. |
70 |
|
71 |
It would resolve the problem but break compatability with every other Linux |
72 |
distribution. |
73 |
|
74 |
> > <snip> |
75 |
> > Actually I think the opposite. Convenience for me is really important. |
76 |
> > The less I have to do the more I'm happy and can do something else. |
77 |
> > That's why I'm complaining at the first place. I've merge a couple of |
78 |
> > time baselayout and while this package shouldn't be updated frequentely |
79 |
> > IMHO it shouldn't be kept idle either if it can still be enhanced. |
80 |
> > Therefore I think to make the thing more convenient and less annyoing we |
81 |
> > should enhance it a little more. |
82 |
|
83 |
Quite franky, convenience should never be given priority in cases like this. |
84 |
System updates should be as convenient as possible *without compromising the |
85 |
system*. We're not talking about making it easier to read your email, we're |
86 |
talking about modifying a core system directory with files that are critical |
87 |
to the proper operation of the system. Convenience is and should always in |
88 |
such cases be secondary to stability and security. |
89 |
|
90 |
-- |
91 |
Matt Beland |
92 |
matt@××××××××××××××.org |
93 |
http://www.rearviewmirror.org |