1 |
On Mon, Mar 11, 2002 at 01:16:45PM -0500, Yannick Koehler wrote: |
2 |
> Craig M. Reece wrote: |
3 |
> >On Mon, Mar 11, 2002 at 12:48:08PM -0500, Yannick Koehler spoke thusly: |
4 |
> > |
5 |
> >>Guys, |
6 |
> >> |
7 |
> >> not sure for anyone else but is init.d really need to be protected? |
8 |
> >> I mean does someone really change files in that directory (other |
9 |
> >> than adding or removing)? |
10 |
> >> |
11 |
> >> That dir should always get merged. It would also get really nice of |
12 |
> >> the portage could detect that no changes has been made to the file |
13 |
> >> since its installation and therefore merge it without any issues. |
14 |
> >> |
15 |
> >> Like if the protected config file's time were saved in a temp files |
16 |
> >> that portage would look into before merging to see if the date has |
17 |
> >> or not change since the last install. |
18 |
> >> |
19 |
> >> |
20 |
> > |
21 |
> >Yes it needs to be protected. I, for instance, have my own version of |
22 |
> >pcmcia in there that I don't want stepped on. Also, I have a couple of |
23 |
> >other custom scripts for things not in portage yet; and when they are in |
24 |
> >portage, I want to be able to compare the differences before using one |
25 |
> >or the other. |
26 |
> |
27 |
> The reasoning I have is that those are scripts, and not config files. |
28 |
> If ... instead of modifying pcmcia script for example like you |
29 |
> mentionned you were to cp pcmcia pcmcia.modif and rc-update add |
30 |
> pcmcia.modif default / rc-update del pcmcia default the system would |
31 |
> work and you'll never get concerned about the new pcmcia scripts. |
32 |
|
33 |
They are sometimes both scripts and config files. Personally, I like the |
34 |
layout of the Gentoo initscripts, particularly with regard to the "local" |
35 |
script and the ability to start "simple" daemons and scripts with a config |
36 |
file. However, many of the scripts we add to the init.d directory are not |
37 |
custom-written for Gentoo, they're written for Linux in general. They |
38 |
include the necessary config settings in the init file itself. And those |
39 |
should not be clobbered. |
40 |
|
41 |
> If you changes those scripts maybe it's even better to tell people about |
42 |
> your changes as they may get implemented such that the script itself |
43 |
> read a config files (like net.eth0) so that other people can re-use your |
44 |
> modifications. |
45 |
|
46 |
That's fine for things like the tweaked pcmcia script - but what if the |
47 |
tweaks are in order to permit a specific driver to work properly? Those |
48 |
changes should not be in the default initscript, they should at most be |
49 |
provided as a commented-out section - which, again, would require user |
50 |
intervention to create the required "tweaked" script. |
51 |
|
52 |
It wouldn't solve the problem for custom scripts. Suppose (as an example) |
53 |
that I have installed OpenSSH by compiling it from source, then later |
54 |
I emerge the ssh ebuild. I would have installed an initscript already, |
55 |
I would call it 'sshd' by default. Before I blindly replace it with the |
56 |
Gentoo initscript, I would want to examine it and see how it did things. |
57 |
|
58 |
> And maybe a user's scripts directory should exists, something like |
59 |
> /etc/user.d where people can move their custom scripts and the stuff |
60 |
> behind rc-update would got here first and if it doesn't found the script |
61 |
> then to /etc/init.d. |
62 |
|
63 |
While I don't agree with everything that "the standard linux" build does, |
64 |
particularly as defined in the LSB project, I don't think we should be |
65 |
creating new directories within /etc/ just to make things a little more |
66 |
convenient. Especiually when that convenience comes with a price in the |
67 |
form of an increased risk of system breakage. |
68 |
|
69 |
-- |
70 |
Matt Beland |
71 |
matt@××××××××××××××.org |
72 |
http://www.rearviewmirror.org |