Proposed guideline for init script files

Michael Schwendt bugs.michael at gmx.net
Thu Mar 1 02:12:04 UTC 2007


On Thu, 01 Mar 2007 01:09:05 +0100, Scholz wrote:

> >> >> /etc is the classical location for configuration files and I
> >> >> *expect* that I can edit things there resp. that my changes are
> >> >> not lost silently.
> >> >
> >> > /etc contains things, such as GConf2 schema files, which you are not
> >> > supposed to edit.
> >> 
> >> Then, they do not belong into /etc and should be moved out it.
> >
> > Even if they contain configuration related defaults?
> 
> When the defaults can be changed by the administrator, the schema files
> must be %config (at least). When they are static the schema files must
> be moved out of /etc.

They can be changed and used by an experienced adminstrator. But
making rpm create *.rpm{save,new} files would not be wise, since the
package scriptlets do the gconftool-2 dance with --makefile-uninstall
and --makefile-install, which better works with the right schema files.

> > But only *if* there is no other place where to customise the service
> > config, e.g. /etc/sysconfig.
> 
> Sorry, how can a system administrator know which configuration files are
> supposed to be editable? Do we require a big fat "### DO NOT EDIT THIS
> FILE" header for each initscript? Or require a-w permissions for them?

Is it the same sysadmin, who deals with *.rpm{save,new} initscripts?
Seems to be either a marketing/documentation problem or broken/insufficent
initscripts, when it is assumed that this is the proper way to configure
a service. If the modification is only applied to fix something, we're
back at the better-fix-the-vendor's-package case.

Anyway, to find an end, I don't want to object strongly when it comes
to keeping initscripts %config. I just don't buy the argument that this
is a necessity because having to fix bugs in them, while the Fedora 
package is not fixed, happens too often. Again, then one could also
justify that Python files, Perl files, and so on, are marked %config.




More information about the Fedora-maintainers mailing list