Re: init script config files
Martin Bialasinski wrote:
>> Also, I oppose the idea, that part of the scripts in /etc/init.d
>> are conffiles and part of them are not. I want consistency and a
>> plain simple scheme (the current one is "init scripts are located
>> in /etc/init.d and are conffiles. Period.").
* "Christopher" == Christopher W Curtis <ccurtis@aet-usa.com> wrote:
Christopher> That's ok, too. I misspoke when I said they should not
Christopher> be. But they do not *need* to be.
So you propose "init scripts are located in /etc/init.d and _can be_
conffiles."? This is flawed.
Christopher> You are correct that what can be done is limited by what
Christopher> the script provides, but the daemon the script controls
Christopher> is also limited.
Sorry? The functions or limitations of the daemon do not determine how
much changes one can/wants to make to the init script. This is no
logical conclusion you draw there.
Christopher> If the script is not comprehensive, then yes, there are
Christopher> definately problems like this.
Problems like what? I can't follow your argumentation.
>> Why would it be easier for the admin to modify these two values in
>> an external file instead of the init script? You make this
>> statement, but what do you have prove for it?
Christopher> It is 'easier' because the script maintainer can provide
Christopher> a new version of the script, perhaps to coincide with a
Christopher> new proftpd that has a new feature or different syntax,
Christopher> and if the admin makes a change (such as the -d 3) there
Christopher> is no conflict because the change was made in an external
Christopher> file, not the script itself.
OK, let's take a step back (and I try to bring in some of the
decisiontheory I am learning right now):
We are discussing alternatives, without really knowledge of the goals.
The init scripts are the interface the admin uses to control daemons.
Fundamental goals ("I want it because of its own merits") are
0. one interface on usage = ./foo start etc.(Any alternative has to
provide this, so we can leave this out)
1. posibility of customisation by the admin
2. ease of upgrade wrt to changes in the maintainer's version of the
script
Any others? No instrumental goals ("I want it because it helps
reaching fundamental goal X") please.
OK let's see some alternatives.
"old style" script
ad 1. admin has complete control of the script. He can change the
commands used, variables etc. No formal structure for customisation,
some scripts define some variables at the top.
ad 2. init scripts are conffiles. If it was changed by the admin, and
changed by the maintainer, dpkg asks what to do on upgrade. The init
script has to be revised and merged manually by the admin.
Christopher's suggestion (please correct me, if I am wrong)
ad 1. if a script is a "old style" one, see above. If a script is of
new style, admin may not change the init script and the way it works
himself. He may only change variables defined in a external
file. Changes only possible to things the maintainer has provided
variables for.
ad 2. if a script is a "old style" one, see above. If a script is of
new stlye, dpkg will install the new init script right away.
Martin's alternative
ad 1. admin has complete control of the script. He can change the
commands used, variables etc. All customisation variables have to be
defined and commented at the top of the script. They have to have
default values, which can be overridden by the admin through vaules
set in an external file.
ad 2. init scripts are conffiles. If the admin changes just variables
defined in the external file, dpkg will install the new init script
right away. If the initscript was changed by the admin, and changed
by the maintainer, dpkg asks what to do on upgrade. The init script
has to be revised and merged manually by the admin.
Note, that my alternative is already possible by policy, and I
wouldn't be surprised if some script already does it that
way. [checking]. At least xdm uses /etc/X11/xdm/xdm.options.
Problem: the "external file" that holds the variables to change is not
defined. I think it would make sense to define how variable definition
have to be made. One synatax instead of multiple ones. [xdm uses
"no-ignore-nologin" or "ignore-nologin". Maybe "ignore-nologin=true",
"timeout=30" or such would be better. "#" as the comment character]
For the later two alternatives, there is the question how to bahave on
a significant change in the init script.
Example:
before: one timeout value, changed in the "external file"
now: incoming timeout and outgoing timeout, so what do we do now
Joey said: "The config.d system makes the files sufficiently simple to
parse that packages can deal with fixing them up after such changes."
I can't really judge this.
Now, we can make up other alternatives, and see if how they behave wrt
out goals.
>> This ("and everything you need to do can be done from there") is an
>> constraint, that I don't see met. You can never say "oh, nobody
>> will ever want to change this script".
Christopher> Well, you could say that if the script supplied doesn't
Christopher> support X without having to be edited, it should be fixed
Christopher> upstream so that others can share in the 'fix'.
You mean the Debian maintainer should fix it, not upstream. The
initscripts are part of the Debian adaptation.
And yes, there are cases where this should be done. But I can imagine,
that such a change may be of interest of very few, but still makes the
init script more complicated. And further more, there is danger that
you end up in a structure like
if A
if B
if C
foo1
else
foo2
elseif D
foo3
else
foo4
elseif E
foo5
else
foo6
Which makes the init script more and more complicated the more options
you consider in the script.
The worst case would be complexity of level O².
One the other hand, an init script that provides for the most common
customisation and a admin that changes it to fit his "strange" needs
would be less complex.
Christopher> But there's no reason they can't coexist, and I'm not
Christopher> trying to dictate anything;
If you mean that a package can either have an "old style" init script,
which is a conffile, or a "new style" init script which is not a
conffile and parses some file for option, then this is not good,
because it makes the interface, then this is not good because of the
"not a conffile" part. This makes the interface (= the files in
/etc/init.d/ behave differently/inconsistent wrt package upgrades).
Christopher> I'm just showing some code that I think would make things
Christopher> easier for everyone, and showing how it would be used.
Christopher> I've not posted any diffs to policy.
It's OK, we are discussing the consequences. Nothing more.
Ciao,
Martin
Reply to: