(REPOST) user-specific package configuration information
The LSB and FHS are an excellent opportunity to start
to cleanup the god-awful mess of how package
configuration information is presently stored in the
user home directories and environment. I have raised
this issue with the FHS group and they consider this
valuable, but regard it as a LSB issue and not a FHS
issue. The FHS 2.2 does specify storage locations for
host-specific package configuration information in
"/etc/opt/<package>" (see FHS 2.2, section 3.7.4) but
does not specify where to store the user-specific
package configuration information.
Presently the storage location for user-specific
package configuration information is in user home
directories in many various "." files or
sub-directories (e.g. ".vimrc", ".gnome"). Please
consider the following possibilities:
1. In addition to requiring full FHS 2.2 compliance,
define one new sub-directory beneath the user's
home directory to hold user-specific package
configuration information. Suggestions for
naming have been "~/etc", "~/.etc", "~/.config"
2. Recommend that each package create one additional
sub-directory beneath this new directory to be
used to hold all user-specific package
configuration information for that specific
package (unless it must reside elsewhere for the
package to function properly).
3. Require that the directory be named the same as
the package name as defined in the LSB.
For example, the package "lsb-foo-1.0-1.i386.rpm"
would store all user-specific package configuration
information for user "joe" (with home directory
"/home/joe") in "/home/joe/.etc/lsb-foo/". This
matches the FHS 2.2 specification for host-specific
package configuration information. For this same
example the FHS 2.2 specifies that the package
"lsb-foo-1.0-1.i386.rpm" store all host-specific
package configuration information "/etc/opt/lsb-foo/"
(FHS 2.2, section 3.7.4).
These changes are not difficult for package
maintainers to implement and automate, particularly in
light of the changes needed for FHS 2.2 and LSB, and
will go a long way towards starting to cleaning up the
present mess in user home directories. The above will
also: (1) avoiding future naming conflicts in the
configuration files, (2) ease maintenance of package
specific configuration information, (3) provide some
inherent self documentation of the configuration
information and (4) provide a standard structure for
packages to upgrade their configuration information is
a very consistent manner.
The present GNOME GConf has recognized the inadequacy
of the present user configuration scheme and proposed
a better solution, however, GConf is not a standard.
Regarding the user environment; what is the minimal
specification for the user environment and are there
any environment variable naming conventions? The LSB
is also a very good opportunity to provide some
standards and guidance to package and distribution
maintainers for setting up and adding to the user
environment. I don't see any references in the LSB of
what to expect in the user environment and I don't see
any naming conventions for package and distribution
maintainers to follow.
For instance, I would hope that everyone could agree
that the minimum user environment would include the
variable "HOME" and should be set to the user home
directory (therefore, able be used by programs)
(except for root). I think that the LSB should define
a minimum user environment that can be expected when
executing programs or installing packages (e.g. HOME,
PATH, SHELL, LOGNAME, DISPLAY, TERM, EDITOR ...).
Also, to avoid possible environment naming conflicts
all LSB packages should prefix all environment
variables that they add to the environment with their
respective LSB package name. For example, the
package "lsb-foo-1.0-1.i386.rpm" should only add
environment variables that have a prefix of
"lsb-foo-". This would furthermore provide inherent
documentation and easier maintenance of the user
Please consider the LSB and FSB as an excellent
opportunity to recommend a better organization for
the user-specific package information and the user
environment. If the present schemes are left
unaltered the problems will continue to grow
out-of-control and will become one of the largest
problems for consistent package management.
Find the best deals on the web at AltaVista Shopping!