on /etc/sysconfig

[Miloslav Trmač]

On Mon, Jul 18, 2011 at 10:57 PM, Richard W.M. Jones <rjones at redhat.com> wrote:
> I'm sympathetic to Lennart's arguments, but really this should be
> discussed and decided in the context of a real, open forum, drawing
> interested people from all of the Linux distros (possibly BSD etc
> too).  Perhaps LSB?

/etc/sysconfig is not a file format standard.
/etc/sysconfig is not a place where configuration files of the same
format or purpose are stored.
/etc/sysconfig is not a place used to store configuration shared by
independent software packages.
/etc/sysconfig is not a software package.

I can't see a reason to discuss /etc/sysconfig as a single unit, nor
to argue for removal of /etc/sysconfig a single unit, nor to try to
form a definite consensus about /etc/sysconfig.


/etc/sysconfig is a conventional place where various
distribution-specific software stores its configuration.

Note the two primary attributes:

* _various_ software: Each file needs to be discussed separately, in
the context of the software that uses it.
/etc/sysconfig/{crond,iptables,nspluginwrapper} have nothing in
common, and need to be considered separately together with the
software that uses these files.

* _distribution-specific_: There's no point in defining a common
standard for software that is not commonly used.  Replacing
distribution-specific software by distribution-shared software may be
beneficial, and it may make the distribution-specific config file
obsolete, but writing the common software common needs to come
_first_.  Only then can we think about making the configuration common
- and often we may find that breaking backward compatibility with
configuration in /etc/sysconfig doesn't buy anything.

This discussion really seems to be not about /etc/sysconfig, but about
"configuration of the distribution-specific software in /etc/init.d
that is scheduled to go away by F16" - but having a plan (and, mostly,
manpower) for removing the code in F16 without having corresponding
plans (_and_ manpower) for agreeing upon, implementing, and
integrating, corresponding software into the various upstreams, is
putting the cart before the horse.
   Mirek