Gentoo Archives: gentoo-dev

From: Matt Beland <matt@××××××××××××××.org>
To: gentoo-dev@g.o
Subject: Re: [gentoo-dev] /etc/init.d
Date: Mon, 11 Mar 2002 12:57:25
Message-Id: 20020311185408.GC28735@rearviewmirror.org
In Reply to: Re: [gentoo-dev] /etc/init.d by Yannick Koehler
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

Replies

Subject Author
Re: [gentoo-dev] /etc/init.d Martin Schlemmer <azarah@g.o>
Re: [gentoo-dev] /etc/init.d Yannick Koehler <yannick.koehler@××××××××.com>