Gentoo Archives: gentoo-dev

From: Yannick Koehler <yannick.koehler@××××××××.com>
To: gentoo-dev@g.o
Subject: Re: [gentoo-dev] /etc/init.d
Date: Mon, 11 Mar 2002 14:44:24
Message-Id: 3C8D1715.8010001@colubris.com
In Reply to: Re: [gentoo-dev] /etc/init.d by Matt Beland
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

Replies

Subject Author
Re: [gentoo-dev] /etc/init.d Martin Schlemmer <azarah@g.o>