Home folder organisation

Posted by: aigarius 7 years, 9 months ago

(11 comments)

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:


  1. Is there something better in $HOME/.cache/appname vs. $HOME/.library/appname/cache ? Any other trade-offs that I have forgot?

  2. What do you think about the further idea of users having the ability to install software in their home folders or remove such software in a very simple fashion?

Currently unrated


Comments

  • jcdubacq 7 years, 9 months ago

    The cache directory could be on a local disk, where as config and data could be on a shared partition.

    Link / Reply
  • harrytuttle 7 years, 9 months ago

    it may be interesting to look at how autopackage handles this.

    Link / Reply
  • Stoffe 7 years, 9 months ago

    Please please either make this compliant with the freedesktop spec or work to change that spec - we don't need more fragmentation anywhere. This doesn't mean you have to use their suggested directories, but the env vars should be properly set and working, so freedesktop compliant apps "just work". I've already seen a number of them among the younger ones.

    Otherwise, I applaud this effort, it's *so* needed. Installing apps locally is a nice extra benefit, but order in the chaos is essential.

    Having a (regenerating) ~/.cache directory would make it easy for end-users to "rm ~/.cache" easily in a number of ways, which could be useful and is also an easily copy-pasted tip.

    Link / Reply
  • aigarius 7 years, 9 months ago

    My plan of action entails replacing that freedesktop.org spec with whatever we decide here and then simply reference that in Debian Policy and the FHS.

    Link / Reply
  • Olaf van der Spek 7 years, 9 months ago

    > Is there something better in $HOME/.cache/appname vs. $HOME/.library/appname/cache ? Any other trade-offs that I have forgot?

    Why don't you introduce an API that apps can use to find out the right directory instead of 'hard-coding' this?

    Link / Reply
  • aigarius 7 years, 9 months ago

    > Why don’t you introduce an API that apps can use to find out the right directory instead of ‘hard-coding’ this?
    I do not want to introduce anything that would force any significant change to *all* applications, as this would. The less changes are needed in *every* program in the world, the higher chances are of this coming to reality.
    That is one of the biggest concerns that I have with this - I can decide anything, but it will be useless if it just lies there for years, like that freedesktop.org specification.

    Link / Reply
  • dom 7 years, 9 months ago

    .library/appname makes wiping out/restoring all application config/data super easy which I like. The location of the cache is six one way, a half dozen the other. Having all application data together is very nice so I would vote for ~/.library//{config|data|cache}

    Link / Reply
  • Kelly Clowers 7 years, 9 months ago

    I think this is a great idea. I have tried to setup something like this with a ~/var directory and symlinks from the original cache locations into ~/var, but it is a pain to do manually.

    I think if everything was in ~/.cache, it would be easy to clean it all at once and easy to see if all the space in your home dir is being used up by programs and documents or just cache files.

    Link / Reply
  • Tortanick 7 years, 9 months ago

    I love this idea, my vote is for $HOME/.library/appname/{cache|config|…}

    but I would prefer that it is $HOME/.library/appname/{var|etc|…}

    I would however suggest a slight modification to this scheme, rather than having $HOME/.library you have $HOME/.catalogues/{current|distroA|distroB} current is a symlink to distroX, during bootup a linux installation will change every $HOME/.catalogues/current to point to the correct catalogue for that installation, for example you may have $HOME/.catalogues/{current|debian|suse|gentoo|debiandevelopment}

    The reason being that if every app looks in $HOME/.catalogues/current/appname then it becomes very easy to manage where the diffrent files go, some may be on a NFS partition (e.g. shareing you're thunderbird profile and E-mails with other computers), others in $HOME/.libary (shareing between multiple distros) and more in /var/libary/username (not shared between multiple distros)

    I invision a synaptic like tool that lists all you're installed programs, for each one you can chose any libary (just a list of folders the user chose to use as libaries). If you change the libary for a perticular program (say mozilla) it will:

    mv //mozilla //mozilla
    rm $HOME/.catalogues/current/mozilla
    ln -s //mozilla $HOME/.catalogues/current/mozilla

    Link / Reply
  • Tortanick 7 years, 9 months ago

    Looks like the last 3 lines didn't come out well because I used "greater than" and "less than" symbols, so here they are again without them.

    rm /old location/mozilla /new location/mozilla
    rm $HOME/.catalogues/current/mozilla
    ln -s /old location/mozilla $HOME/.catalogues/current/mozilla

    Link / Reply
  • Tortanick 7 years, 9 months ago

    *sigh* not my day, third time's the charm

    mv /old location/mozilla /new location/mozilla
    rm $HOME/.catalogues/current/mozilla
    ln -s /new location/mozilla $HOME/.catalogues/current/mozilla

    Link / Reply

New Comment

required
required (not published)
optional

Recent Posts

Archive

2014
2013
2012
2011
2010
2009
2008
2007
2006
2005

Categories

Authors

Feeds

RSS / Atom