Re: (REPOST) user-specific package configuration information
On Wed, 04 July 2001, Theodore Tso wrote:
> they don't really "clutter" the home directory
Understood, but my perspective is different.
> And by being in the user's home directory, they're easy
> for programs to find, and easy for system administrators
> to back up.
Its just as easy to backup a single directory (~/.etc) and
much easier to find the configuration files for a particular
package (~/.etc/<package name>/*).
> On top of that, there is the entrenched history to consider.
Yes, but I can remember when entrenched history was to store
the users home directory in the /usr directory. My point is
that if it is a problem, and it can be fixed, then it
eventually will be. However, without proper foresight, not
until it grows to be a big problem. And I do agree that
sometimes foresight is wrong and you waste time fixing
problems that are not real problems.
> the likelihood of this changing in the near future is small
I agree, not in the near future ... but eventually it will
change ... which is my point. I would prefer to have a
new scheme now where the change can happen gradually over
time. I think that the LSB is a good opportunity to
recommend a new scheme that has merit. If no one uses it,
then fine and it dies ... nothing is lost since it would
not be a mandatory requirement anyway, but if developers
start using it and it grows then we all benefit.
> The question you raise is much like one of whether
> individual files should be in /etc, or in directories.
> i.e., /etc/exim.conf, vs. /etc/exim/exim.conf
Two points: (1) not quite the same since only a single
directory (e.g. ~/.etc) is used to hold all user-specific
configuration package information for all packages, and
(2) the present LSB 1.0 requires that the exim package be
named something like lsb-exim-2.12-x.i386.rpm, and
therefore, the FHS requires the configuration file
"exim.conf" be stored in the directory "/etc/opt/lsb-exim".
So actually there is no question anymore as this file must
If not then the package will not be LSB or FHS compliant.
And I agree with this ... even if the structure is more
complex it identifies various attributes of "exim.conf";
(1) the file belongs to an optionally installed package,
(2) the package is LSB compliant, (3) the package name is
"lsb-exim" and (4) it is the only configuration file
for this package.
> So the issue is much more complicated than you make
> it out to be....
I disagree. I am not a newbie. I have been very
involved with *nix systems technically for 30+ years
(however, Linux for only 2). I really think the
largest hurdle in not technical complication at all,
but pacifying the community members that get
"religious" about these types of issues. The things
to keep in mind are:
(1) technical merit for change is clearly shown,
(2) backward compatibility is fully maintained and
(3) continued use of the status quo is permissible.
I think this proposal passes on all three criteria.
However, seeing the responses so far I don't think
it will fly ... to bad :)
Best Regards, Keith Adamson
Find the best deals on the web at AltaVista Shopping!