[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 environment.

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.

Keith Adamson


Find the best deals on the web at AltaVista Shopping!
http://www.shopping.altavista.com



Reply to: