[RFC] User Accesable Filesystem Hierarchy Standard

[Doncho N. Gunchev]

On Wednesday 07 April 2004 04:56, Jamethiel Knorth wrote:
> Date: Mon, 5 Apr 2004 16:39:18 +0300
> From: "Doncho N. Gunchev" <mr700 globalnet bg>
> >
> >On Sunday 28 March 2004 00:34, Gary L Greene Jr wrote:
> >>
....
> >    Let's say we have program foo from package foo-1.0-1.sparc.rpm which has
> >a .desktop file in ~/.<distribution>/share/applications/foo.desktop.
> >--- cut ---
> >+------------------------+---------------------------------------------------+
> >| ~/.<distribution>/share/ | Architecture independent files used by programs |
> >|                          | in ~/.<distribution>/<architecture>/bin/        |
> >+--------------------------+-------------------------------------------------+
> >--- cut ---
> >    In this case if a user uses his home from a nfs share on ix86 mahine
> >he/she will see this application in his/her kde/gnome start menu, but will
> >not be able to run it (it is the sparc version, not the ix86). Another
> >problem could be shared files that are little-endian/big-endian dependent.
> >The space could be saved by hardlinking identical files which are not
> >suposed change without being removed first (/usr/share/doc/*/*).
> 
> There will likely need to be separate menu entries in each <distro>/<arch>/ 
> directory, but that's really up to the desktop's to introduce. I don't think 
> this standard in any way prevents that from being added. Or, they might be 
> able to add some extensions to the XDG standard (or whatever the new menu 
> standard is) to allow different entries according to distro and 
> architecture.
    Could work with extra tags in the .desktop entries or with some sort of
tag, extension, etc. I'm still not sure what happends with programs that
use architecture dependant data ordering (big-endian and little-endian).
Probably the programs must be fixed, but to me it looks much more simple
having only a BASEDIR and all bin,etc,lib,... dirs there. Installation
programs (rpm,dpkg...) or the user can still hardlink/symlink files.

> 
> >    What about uafhs being configurable via /etc/uafhs? It could be 
> >something
> >like 'UAFHSBASE="$HOME/uafhs/$ARCH/$DIST-$DIST_VER"'. This way only a 
> >script
> >will be needed to setup this variable at login time and the install tools
> >should be made UAFHS-aware (or at least I hope so). The main idea is to 
> >allow
> >a user to login from same/different distribution(s) and architecture(s)
> >simultaneously. I have RH9 + FC1 with shared /home partition and this leads
> >to many problems with all .dot(files|dirs) in my home dir (kde for example)
> >even without logging in simultaneously.
> 
> I had been considering this problem a little, but was unsure how large of a 
> problem it was, as I have never had parallel distribution installs. I 
> considered having '.<distro>/<arch>/config/' instead of '.config' to avoid 
> this, but my concern was that this would mean the directory had a totally 
> non-constant location, and many programs wouldn't use it. Of course, 
> distribution builds could use it well enough, but something installed from a 
> tarball might be hard to convince. If this were the case, the '.config/' 
> directory wouldn't actually clean up the dotfiles in the home directory, as 
> it was intended to do.

    If something compiled from tarball uses BASEDIR=UAFHSBASE I think there
is no problem except for all dotfiles in the home dir. If such a program is
UAFHS-aware there should be no problem at all I hope...

> 
> As you use a parallel install, how large of a problem is this? I mean, I 
> truly don't know. Also, would moving the config directory into the 
> distribution and architecture directories solve this properly?
> 

    KDE uses some way to update the config files to the newer version,
but it often fails. Once I had to "mv .kde .kde-old" and copy and fix
only what I really need (address book, etc) in order to get kicker
working again.
    OpenOffice erased all my dotfiles (not dirs or normal files) when
I upgraded from RH9 to FC1 (If I remember correct). When I started
oowriter a reinstall/uninstall dialog popped up. I clicked Uninstall
and... I'm not 100% sure it did (I never repeated this experiment),
but I did almost nothing else at that time. Look at the list at
http://www.redhat.com/archives/fedora-list/2003-November/msg02203.html
for example.
    Because of all this and because all distributions use different
program versions and patches (only RedHat ships MC with UTF-8 patch
AFAIK /this makes no problem for me/) I think having different
locations (maybe with option) for user configuration files is better.
After all you can easily symlink them all to point a single directory,
a program can also add such symlinks to /etc/skeleton.

    I think the idea for '/etc/uafhs' and 'UAFHSBASE' is good, because
it allows you to adjust it per distribution. Assuming FCx for i386
and FCx for x86_64 uses the same set of applications you can skip the
architecture tag or better symlink their etc dirs. Sadly, this makes
the things much more complicated, but gives you more flexability.
    In short and rought shape I see UAFH like FHS with '/', '/usr'
and '/usr/local' merged under $HOME/<configurable_dir(s)>/, but of
course I can be totally wrong :)

-- 
Regards,
  Doncho N. Gunchev    Registered Linux User #291323 at counter.li.org
  GPG-Key-ID: 1024D/DA454F79
  Key fingerprint = 684F 688B C508 C609 0371  5E0F A089 CB15 DA45 4F79