Re: Standardizing ~/.cache/ and similar things.
Dear Debian developers,
here is a proposal I submit for inclusion in the debian policy:
PROPOSAL 1: ~/.cache/${package_name}/
All packages that keep a per-user directories caches of data that need
not be archived/backed up should put it in ~/.cache/${package_name}/
instead of wherever they put it currently.
Rationale: KHTML, Mozilla, w3m, slime, etc., all use different
directories: ~/.kde/share/cache/, ~/.mozilla/$USER/$CODE/Cache/,
~/.w3m/, ~/.slime/, etc. When duplicating some user's settings (from
one machine to another, from one user to another, etc.), or when doing
a backup, this means a lot of useless data will be copied over, or
non-reliable ad-hoc exclusion lists must be devised. Putting things in
a well defined location will tremendously help system administrators,
while providing users with a well-defined interface for keeping things
in or out of backup: put things physically in or out of ~/.cache/, add
use symlinks to ensure proper access through logical paths.
Cost to users: the ~/.cache/ hierarchy is not used yet, so there is no
cost to user.
Cost to implementors: all packages that keep a cache must be modified.
A way to move the previous cache must be devised. Symlinks from
previous location might have to be provided for backwards
compatibility.
Note: this might (or not) also replace things like
/var/cache/$package/$user that have an intrinsic security problem if
some other user tries to hijack the cache before the user uses the
program.
PROPOSAL 2: ~/.etc/${package_name}/
All packages should put their configuration in ~/.etc/${package_name}/
instead of ~/.{weird_variation_on_package_name}. Moreover per-user
~/.etc/ hierarchy should be essentially the same as the /etc/
hierarchy, in terms of mapping configured functionality to filename.
Thus, no more ~/.zshrc. but instead ~/.etc/zsh/zshrc (or ~/.etc/zsh/rc
if they shorten the name).
Rationale: this solves the mess of files in ~/, which makes the
directory browsable once again, and allows for intelligible management
of what files should be kept for the purpose of which package, or what
can be safely deleted.
Cost to users: the transition period may involve some breakage, unless
symlinks are provided. Said symlinks are still cruft that will have to
be cleaned up later.
Cost to implementors: almost every package must be modified.
PROPOSAL 3: ~/.run/ ~/.lib/ ~/.share, etc.
Programs that insist to install stuff in the user's directory (such as
openoffice, gimp, etc.), or that have runtime files (such as emacs'
.saves-*) should put this stuff in a proper hierarchy that mirrors the
categories of the FHS, only on a per-user basis. This will help
administration of per-user installed stuff in the same way that the
FHS helps with machine-global installed stuff.
Cost to implementer: if we already to proposal 1 and 2, the
incremental cost is low. If things are properly designed, this could
actually simplify a bit of the cruft in existing programs, that do
things with random unrelated filenames, and will do thing with
uniformly chosen filenames instead.
NB: I've send a similar proposal to the FHS mailing-list. I'm trying
to get the message to as many free software developers and packagers
as I can. I have 280 files and directories that match .* in my home
directory, and hundreds of megabytes of cruft in there if I wanted to
duplicate it as is when creating an account on a new machine.
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
They laughed at Columbus, they laughed at Fulton, they laughed at the
Wright brothers. But they also laughed at Bozo the Clown.
-- Carl Sagan
Reply to: