On Sat, Jan 04, 2003 at 07:21:11PM -0600, Jamin W. Collins wrote:
> A while back, on one of my other lists, there was a discussion about
> user configuration files for the program and where to put them. That
> led to how frustrated many users were with the dot files just littering
> their home directory. One suggestion that came out of it that I liked
> was to put all the user configuration files under a sub directory such
> as ~/.etc. This way the user's home directory is left uncluttered and
> the structure more or less reflects that of the system-wide
> configuration files.
>
> So, what do you folks think? Would it be worth while to have a Debian
> policy regarding the placement of user configuration files in a
> configuration sub directory of the user's home dir?
The problem with this is that it contradicts what the vast majority of
the upstream software we package does, and what that same software will
do if people compile it for themselves. While we certainly do have
various pieces of policy that require changes to software when it's
packaged (the editor and pager policies come to mind), these tend to be
a matter of default configuration, and don't cause interoperability
problems with a plain unpatched version the user has installed from
source in /usr/local. We already express this principle in policy 11.7.5
('User configuration files ("dotfiles")'): "Furthermore, programs should
be configured by the Debian default installation to behave as closely to
the upstream default behaviour as possible".
In other words, somebody will be told "that bug's fixed in the
development version of this package upstream", so they go and try it
out. But, hey presto, not only does it ignore the configuration set up
while using the Debian package, but it also creates some new stuff in
the home directory that we had hypothetically promised to keep pristine.
I think this would be completely unacceptable. To avoid this, we'd have
to convince every affected upstream to do this before we could implement
it across the board. That's just not going to happen without some
momentum behind it, and general agreement from the community, not just
on some obscure Debian list, that it's a good idea.
Not to mention that the '.' namespace hack is not all that bad. It's
clearly separated and well-known, it sorts separately from all the other
files in your home directory, and it doesn't clutter all that much
because good file management tools tend not to display it by default.
With a bit of discipline you can even keep it relatively uncluttered,
particularly if you check your home directory into revision control. If
I were designing Unix and all its software from scratch I'd probably do
it differently, but as it stands it's certainly not a disaster and
doesn't cause any non-cosmetic problems.
Basically, I don't think it's the place of Debian policy to recommend
something like this that flies against all of our packages and that
doesn't have a basis in standards constructed by the community at large.
On the other hand, it might well be useful to have something in policy
11.7.5 that says "packages should keep user configuration in dotfiles by
default, rather than cluttering the user's home directory with plain
files". I know that I'm much more annoyed when I run some program and it
creates a non-dotfile in my home directory without me explicitly telling
it to do so (~/lynx_bookmarks.html, for instance; I've long since
configured it otherwise in .lynxrc, so I've no idea if that's still the
default location) than I am with the whole dotfile system.
Cheers,
--
Colin Watson [EMAIL PROTECTED]
