Re: (REPOST) user-specific package configuration information
On Wed, 04 July 2001, Theodore Tso wrote:
> My sense is that it's probably better to deal with this for
> new applications than to ask existing applications to change
> the ways things are done.
I fully agree. The proposal should only depreciate the use
of the user's top-level home directory and recommend a better
alternative *standard* scheme. In no way should existing
applications be forced to comply. There is no way that
forcing compliance would be agreeable to the community.
> In particular, third party application vendors
> (Oracle, for example) will have *zero* interest in doing
> something different under Linux; they will want consistency
> across all architectures, and when talking about Linux
> compatibility, it's important to remember what's the tail
> and what's the dog.
I agree. The proposal should be compatible with all *nix
systems (as the FHS is). However, the FHS 2.2 is forcing
applications to change. For instance, an application must
store the system-specific configuration information in
directory "/etc/opt".
If the proposal for the new scheme is only a recommendation
and not mandatory, then the vendors can chose to;
1. Not comply with the new scheme.
2. Implement the new scheme for Linux system only.
3. Implement the new scheme for all *nix system.
However, I really don't consider implementing a new scheme
a big problem for third party application vendors. For
instance, on startup an application can easily be
programmed to identify the type of system on which it is
installed and setup a parameter that defines the location
for the user-specific configuration information (be it in
the top-level of the users home directory or elsewhere).
The application can even store this information statically
in the system-specific configuration information directory
defined in the FHS 2.2 ("/etc/opt"). The application code
modifications that are be needed to implement the new
scheme are somewhat minor. The programmer needs to search
the application code for all references to the affected
files and introduce the new parameter.
>
> And for new applications, many of which will be GUI
> applications for GNOME and KDE, it's probably best that
> configuration issues be standardized as part of the GNOME
> and KDE projects.
>
I agree, but even GNOME and KDE applications need to store the
persistent user-specific configuration information somewhere
below the top-level of the users home directory (in files and
directories). The proposal for a new scheme is only a means
to better organize the location of these files and directories
(and not to alter or change them in any way) rather than
having them clutter the users top-level directory.
>
> It's much easier to standardize something which is already
> in common practice, instead of trying to use a standard to
> try to coerce people change things to some particular
> person's pet way of doing things. While that can be done,
> it needs to be done very carefully, and for good reasons.
> So the real question is trying to balance the costs and
> the benefits of a proposal like yours.
>
I agree again. There needs to be consensus and there needs to
be justification for change. The justification I've thought
of is;
1. Ease maintenance of user-specific package configuration
information.
2. Avoid possible future configuration naming conflicts.
3. Provide inherent documentation for the configuration
data that belongs to a particular application.
4. Organize and provide a more professional appearance of
the users home directory.
5. Provide a standard guideline for developer to follow for
storing user-specific package configuration information
I really don't expect the present scheme to last forever.
Someday the users home directory will be split from the
location where user-specific configuration information is
stored. The sooner this is done the easier it will be.
Ultimately, this may be the best justification for doing
this now when there is a good opportunity.
Best Regards, Keith Adamson
Find the best deals on the web at AltaVista Shopping!
http://www.shopping.altavista.com
Reply to: