On Wed, 2007-02-28 at 14:46 +0100, Laurent Rineau wrote: > On Wednesday 28 February 2007 13:59:29 Christopher Blizzard wrote: > > On Tue, 2007-02-27 at 15:37 -0500, Jesse Keating wrote: > > > The Packaging Committee has been discussing guidelines for init scripts > > > for a while. Currently there is a split between init scripts being > > > marked as %config and many that aren't. We (the PC) with input from > > > various folks feel it is best to not mark init scripts as %config, and > > > instead promote configuration to happen in an /etc/sysconfig/<init> file. > > > Mostly the reason being that init scripts are just that, scripts to run > > > and not config files to edit. As such I've drafted a proposal for the > > > guidelines and the PC approved it. There is time now for a wider > > > audience to review the proposed change and comment. > > > > +1. In general if you have to edit an init startup file, it's a bug. > > Configuration should be in /etc/sysconfig/foo. > > Right. But are we sure our scripts are configurable enough for usages of all > administrators? > > As an administrator, I would like to be able to use Fedora without filling a > bug when my local settings are incompatible with Fedora's init scripts. > This was my only complaint with the policy. I think it needs to emphasize the importance of packagers exposing configuration options to the enduser. Otherwise we put users in the unenviable position of having their necessary changes silently lost with every update. Matthias's suggestion to have a Best Practices section that outlines what a proper init script will help as well. There should be a section that talks about exposing customization. Here's a snippet for exposing the command line: ''' If your daemon can be customized via environment variables or commandline switches, then you need to expose that to the end user. Do this by 1. Creating an /etc/sysconfig/DAEMONNAME file to store the configuration in. Be sure to add comments to this file that indicate what variables it will know about. 2. Your init script must source that config file. 3. If the daemon you're starting takes commandline options, one of the variables must be DAEMONOPTS which your init script will use when it invokes the daemon. Be sure that this variable allows the user to override any commandline options you've placed in the file. If the daemon does not override arguments but rather spits out errors (like "-v and -q are incompatible. Please specify one or the other.") you may have to place the default commandline options in the sysconfig config file. ''' We should also have some rough guidelines of what customization would be so invasive that a separate package should be built instead of trying to support it in the initscript/config file. For instance, managing the package in a chroot might be something that is configured by dropping a second package on the system that has a different init script and a chroot environment setup. The one thing that I see as the worst of all worlds is encouraging a situation where initscripts are not config and we simultaneously have packages where bugs about customization are considered low priority. -Toshio
Attachment:
signature.asc
Description: This is a digitally signed message part
-- Fedora-maintainers mailing list Fedora-maintainers@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers
-- Fedora-maintainers-readonly mailing list Fedora-maintainers-readonly@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
