[RFC] User Accesable Filesystem Hierarchy Standard

[Jamethiel Knorth]

>Date: Wed, 7 Apr 2004 13:25:43 +0300
>From: "Doncho N. Gunchev" <mr700 at globalnet.bg>
>
>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...

So, a reasonable solution seems to be to just require that $UAFHS_DISTRO and 
a $UAFHS_ARCH variables be present, so an installing or running program can 
look in the right place. Thus, a private install could use 
--prefix=~/$UAFHS_DISTRO and 
--whatever-the-other-prefix-var-is=~/$UAFHS_ARCH and shared/group installs 
could do likewise but in something besides ~/.

The system would just be required to properly declare $UAFHS_DISTRO and 
$UAFHS_ARCH on startup, which would be very simple, quite as declaring the 
PATH variable, and all the other environment variables that are about.

Then, when looking for config files, a program could always look in 
~/$UAFHS_ARCH/config/ to find the config files which are relevant at the 
moment. The only downside might be that your configuration files you go to 
the trouble of setting up on one system would be totally absent on another. 
Creative symlinking might get around that, but I have doubts. Maybe someone 
could think of a good tool to keep that stuff synced.



As you might have some knowledge about this, I'll ask: There are a few 
directories which, after looking, I realized were probably distribution and 
architecture independent which I wanted to place outside of the distro 
folders in these sections. The only ones I noted were font and dictionary 
files, as I don't see where those change from system to system (except 
possibly with the byte-order changes from architecture, but they're already 
in the architecture independent folders). Are these files actually distro 
independent, and are there any other major file groups that are as well?

_________________________________________________________________
Limited-time offer: Fast, reliable MSN 9 Dial-up Internet access FREE for 2 
months! 
http://join.msn.com/?page=dept/dialup&pgmarket=en-us&ST=1/go/onm00200361ave/direct/01/