After
last post
about a FHS amendment to address the structure of user's home folders, I
received a lot of comments and there is one very significant thing that
can be changed in the proposal - instead of having
$HOME/{.data|.cache|.config}/appname structure, to change that to a
mandatory $HOME/.library/appname/{cache|config|...} . This version still
has all the benefits of the first solution (configuration for an
application can be easily identified and erase, and all cache can easily
be excluded from backups using "$HOME/.library/*/cache" regexp) and also
has additional benefits, main of which is the ability to later introduce
the concept of user installed packages. The idea is that it would be
possible to support having /bin, /lib and /share subdirectories in these
application directories thus making an ability for the whole application
to e packed in a single directory and allowing the application to be
installed simply by unpacking this directory. I admit that much of this is
glanced over from MacOS X world, but I do not think that it diminishes the
idea itself.
Some problems appear there - support of these
distributed bin folders, support of separate lib folders, handling of
application plugins, handling of dependencies, handling of the application
menu, upgrading notifications for the user software vs. system software.
But nothing there that can not be solved. I feel that this can bring
together FHS and LSB by providing something of an API for software being
installed by users. Having no registry of the software in this solution
allows for some interesting things, for example having multiple versions
of one program just by renaming the application folder.
A lot of
specification work is required here, therefore I proposed a workshop on
this topic in Debconf7. I hope to have something that everyone can agree
on and maybe even some code by then, so that after Debconf7 there can be a
formal policy amendment proposal.
So there are two questions: