Thanks to Jari for confirming agreement with Peter Palfrader's
summary, and for clarifying what is being requested. I don't think
anything more needs to be said about this.
So I hereby formally propose the draft resolution below. I'll give
other members of the TC a few days to weigh in (in particular, to
suggest alternative ballot options if they want any), and then I will
call for a vote.
I've also slightly improved the rationale to take account of Jari's
last message.
Ian.
-8<-
(1) The REMAIL option should not be supplanted or supplemented by
anything in an /etc/default file. The current behaviour of the
mixmaster init script, to examine /etc/mixmaster/remailer.conf's
REMAIL option, is correct.
(2) Policy is clear and correct, and need not be changed.
-8<-
NB THIS IS A DRAFT BALLOT - THERE HAS NOT YET BEEN A CFV
[ ] Choice K: Keep current behaviour and existing policy, as above.
[ ] Choice F: Further discussion
1. As very helpfully summarised by Peter Palfrader, the current
situation is as follows:
o The mixmaster package provides both the client and server
functionality.
o By default the server part (running a remailer) is not enabled.
o To configure mixmaster to run as a remailer the admin has to set
a dozen options in /etc/mixmaster/remailer.conf. Options like
email address, which formats they will accept, whether to run as
an exit or only as a middleman remailer, etc.
o One of those options is the REMAIL setting, which enables or
disables the remailing ("server") part of mixmaster.
o The init script has code to only try starting the mixmaster
daemon, which is only needed when it's being run as a remailer,
when the REMAIL option is actually set to "y" in that config
file.
2. The submitter has requested that instead of checking
/etc/mixmaster/remailer.conf for REMAIL being set to `y',
the init script should read a new setting out of a file in
/etc/default.
3. The submitter relies on this part of policy 9.3.2:
Often there are some variables in the init.d scripts whose
values control the behavior of the scripts, and which a system
administrator is likely to want to change. As the scripts
themselves are frequently conffiles, modifying them requires
that the administrator merge in their changes each time the
package is upgraded and the conffile changes. To ease the
burden on the system administrator, such configurable values
should not be placed directly in the script. Instead, they
should be placed in a file in /etc/default, which typically will
have the same base name as the init.d script. This extra file
should be sourced by the script when the script runs. [...]
4. The committee's role is not to interpret policy; rather our role
includes both determining the appropriate behaviour in a specific
case and also to specify the appropriate policy wording. However,
we should make our decisions based on the all of the available
information, and existing policy documents are a useful input to
that process.
5. The purpose of this section of policy is admirably and clearly
stated by the policy itself. The intent is that an administrator
who wishes to make a commonly-made change to the behaviour of an
init script will be able to edit the file in /etc/default rather
than the script itself. The point of this is that when the package
maintainer improves the script (which happens often), the
administrator only needs to do a trivial merge of the /etc/default
file rather than to deal with a conffile prompt due to the changes
to the script itself.
6. I agree with the policy as stated, and find the wording clear.
There is little room for improvement. I wholeheartedly adopt the
principles and rationale described in the policy text, as a good
basis for the rest of my reasoning.
7. The present situation does not match that described in the policy.
The setting in question, whether to run the daemon, is not recorded
in the init.d script but rather in a different configuration file.
There is no need to edit the init.d script to enable or disable the
daemon. So the reasoning described in the policy does not apply
directly.
8. But we should consider whether an analogous argument can be made.
The reasoning in the policy text could apply to other configuration
files which contain a good deal of complex text supplied by the
package maintainer, and where certain changes might want to be made
by many administrators. In those circumstances it would be useful
to move those commonly-modified configuration options into a
separate file for the same reasons as one wishes to movoe
commonly-modified settings out of init.d scripts.
9. If that were the case then a file in /etc/default might be a good
choice, depending on implementation language and other details.
(For example, in my opinion files in /etc/default ought to be shell
scripts as described in 9.3.2, and if for implementation reasons
the new small configuration file wasn't a shell script then it
ought not to be in /etc/default; also, not all such shell script
configuration fragments ought to be in /etc/default as the package
may well have a better place to put them.)
10. However, this is not the case here - the REMAIL configuration
option which controls daemon startup is indeed in a configuration
file along with other configuration variables, but many of those
configuration variables also need to be modified by an
administrator who wishes to change REMAIL. So there would be
no benefit in moving the REMAIL option into a separate file.
11. Daemon startup can in any case be controlled by adjustment of the
/etc/rc*.d links. These links which are provided specificially for
the purpose of allowing the system administrator control over the
operation of subsystems like this one. The submitter requests the
following arrangement:
/etc/default/* Daemon boot control setup
/etc/<daemon>/<configs> Daemon run time configuration
I disagree. Daemon startup should not be controlled by variables
in /etc/default. Furthermore, I think the distinction being made
here is artificial and serves no useful purpose.
12. Additionally, having the init.d script read the package's
config files to discover whether the system configuration indicates
that the daemon needs to be started, is a good and appropriate
technique. I commend this approach to package maintainers.
13. I therefore conclude that the policy and the package are both
correct. Unfortunately the submitter appears to have misunderstood
both the actual policy text, and the reasoning behind it.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
