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 via email to