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:I really dislike all these hidden dotfiles/dotdirs in my home directory
This is a proposal for a standard to accommodate the accessibility of the
filesystem by end-users. We request discussion on this as a new standard. >The
URL to get to the document is:
http://www.csis.gvsu.edu/~abreschm/uafhs/
I am a member of the Ark Linux team, who is interested in seeing the Linux desktop become a viable option. I apologize for the cross-posting.
and am happy to see someone is working on this. I was thinking it would be
better if we had ~/etc/bashrc instead of ~/.bashrc and so on, but I see much
more general ideas here, so here's what I think looking at it:
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.
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.
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?
_________________________________________________________________
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/
