Comparing FHS 2.3 and 2.1
Manoj Srivastava
I have been trying to determin the changes in FHS 2.3 (as
opposed to FHS 2.1 that we already follow) to see what changes have
occurred.
1) ===
FHS 2.3 adds:
======================================================================
3.3: Specific Options
The following directories, or symbolic links to directories, must be in /, if
the corresponding subsystem is installed:
Directory Description
home User home directories (optional)
lib<qual> Alternate format essential shared libraries (optional)
root Home directory for the root user (optional)
Each directory listed above is specified in detail in separate subsections
below.
======================================================================
We comply.
2)==
In /bin, /bin/ed is no longer mandated, however,
/bin/hostname is. (We comply).
3) ==
Language related to /bin/sh was cleaned up. Mention of Csh
removed. [ and test must be in the same dir now. (We comply).
4)==
Added optional dirs /etc/sgml and /etc/xml. The number of mandatory
files in /etc has dropped. (We comply). It does, however, seem to say
we need /etc/X11/XF86Config instead of our XF86Config-4, and want
/etc/X11/Xmodmap (optional, thank goodness).
********************************NOT COMPLIANT*************
5)==
User specific configuration files for applications are stored in the user's
home directory in a file that starts with the '.' character (a "dot file"). If
an application needs to create more than one dot file then they should be
placed in a subdirectory with a name starting with a '.' character, (a "dot
directory"). In this case the configuration files should not start with the '.'
character.
I have no idea if we comply, but this is a new requirement.
????????????????????????????????dunno????????????????????
6)==
Allows stuff like /lib64 or the like. /media is added as mount
points -- stuff that used to go under /mnt, which is still
retained. There a re a number of required subdirectories under
/media, which we don't have. Also, /srv should exist.
********************************NOT COMPLIANT*************
7)==
/usr/local/etc may be a link to /etc/local,
/var/lib/hwclock/adjtime has been moved here from /etc
So, we have a few minor things to tweak (/media, /srv, and the
XF86Config stuff, and then we should be OK to move to FHS 2.3 in
Etch.
Unless, of course, there are things I missed.
manoj
--
A gen'ral sets his army in array In vain, unless he fight and win the
day. -- Denham
Manoj Srivastava <sriv...@debian.org> <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Wouter Verhelst
> 5)==
>
> User specific configuration files for applications are stored in the user's
> home directory in a file that starts with the '.' character (a "dot file"). If
> an application needs to create more than one dot file then they should be
> placed in a subdirectory with a name starting with a '.' character, (a "dot
> directory"). In this case the configuration files should not start with the '.'
> character.
>
> I have no idea if we comply, but this is a new requirement.
I think we do. This is common sense anyway, most applications I've seen
do it that way.
> 6)==
>
> Allows stuff like /lib64 or the like. /media is added as mount
> points -- stuff that used to go under /mnt, which is still
> retained. There a re a number of required subdirectories under
> /media, which we don't have. Also, /srv should exist.
>
> ********************************NOT COMPLIANT*************
Actually, we are (for new installations; not for upgrades from older
installations). For the /media part, anyway; not sure about /srv.
> 7)==
>
> /usr/local/etc may be a link to /etc/local,
> /var/lib/hwclock/adjtime has been moved here from /etc
>
>
> So, we have a few minor things to tweak (/media, /srv, and the
> XF86Config stuff, and then we should be OK to move to FHS 2.3 in
> Etch.
I happen to think the XF86Config stuff is braindead. It's full of a
number of assumptions that happen to be correct at the time of writing,
but that may no longer be correct at some point in the future (to name
just one, the idea that XFree86 will be the X server of choice for all
unices trying to comply with FHS).
--
EARTH
smog | bricks
AIR -- mud -- FIRE
soda water | tequila
WATER
-- with thanks to fortune
Henrique de Moraes Holschuh
> On Tue, Oct 26, 2004 at 03:02:02PM -0500, Manoj Srivastava wrote:
> > 5)==
> >
> > User specific configuration files for applications are stored in the user's
> > home directory in a file that starts with the '.' character (a "dot file"). If
> > an application needs to create more than one dot file then they should be
> > placed in a subdirectory with a name starting with a '.' character, (a "dot
> > directory"). In this case the configuration files should not start with the '.'
> > character.
> >
> > I have no idea if we comply, but this is a new requirement.
>
> I think we do. This is common sense anyway, most applications I've seen
> do it that way.
It is probably a good idea to mention this either on policy itself (just to
remind people), or on the packaging guide and maintainers reference. This
requirement is something the maintainers have to watch out for...
Somehow, I just know we will have someone complaining of this FHS
requirement soon.
> Actually, we are (for new installations; not for upgrades from older
> installations). For the /media part, anyway; not sure about /srv.
We should do better than that, I think. We should offer to migrate the
links, /etc/auto* and /etc/fstab entries to the new media scheme on
upgrade.
> I happen to think the XF86Config stuff is braindead. It's full of a
Agreed. It should shunt X-server stuff to X11/ and that's enough...
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to debian-pol...@lists.debian.org
Joey Hess
> User specific configuration files for applications are stored in the user's
> home directory in a file that starts with the '.' character (a "dot file"). If
> an application needs to create more than one dot file then they should be
> placed in a subdirectory with a name starting with a '.' character, (a "dot
> directory"). In this case the configuration files should not start with the '.'
> character.
>
> I have no idea if we comply, but this is a new requirement.
A few things that come to mind are:
- gnome: .gnome, .gnome2, .gnome2_private, .gnome-private all in my
home directory, some are used by multiple apps. Maybe this squeaks by
since there are subdirs, not files?
- WindowMaker: ~/GNUStep is not a dot file (can be made to use
something starting with a dot, via an environment variabe)
- offlineimap (.offlineimaprc, .offlineimaprc.py, .offlineimap/)
- X (.Xauthority, .xinitrc, .xsession, .xsession-errors,
.Xresources, .Xmodmap, etc) But perhaps X is more than one
"application", dunno.
- CVS (.cvsrc, .cvspass)
- scummvm (.svummvmrc and .scummvm/)
- vim (.viminfo, .vimrc, maybe .vim/)
- zsh (.zcompdump, .zlogin, .zshenv, .zshrc)
- ion2 (.ion2/.welcome_msg_displayed ; the filename should not start
with a dot in order to comply)
> ????????????????????????????????dunno????????????????????
>
> 6)==
>
> Allows stuff like /lib64 or the like. /media is added as mount
> points -- stuff that used to go under /mnt, which is still
> retained. There a re a number of required subdirectories under
> /media, which we don't have. Also, /srv should exist.
>
> ********************************NOT COMPLIANT*************
Note that new sarge installs should be basically /media compliant,
although I don't know if we have every subdir the FHS may require in
there. And we still have a /cdrom link to /media since some programs
(like apt) have not transitioned.
I don't belive it's possible to safely automate an upgrade of an
installed system to use /media.
/srv exists on new installs, may not be added on upgrade (I forget).
Is not used by anything yet AFAIK.
--
see shy jo
Bill Allombert
> On Wed, 27 Oct 2004, Wouter Verhelst wrote:
> > On Tue, Oct 26, 2004 at 03:02:02PM -0500, Manoj Srivastava wrote:
> > > 5)==
> > >
> > > User specific configuration files for applications are stored in the user's
> > > home directory in a file that starts with the '.' character (a "dot file"). If
> > > an application needs to create more than one dot file then they should be
> > > placed in a subdirectory with a name starting with a '.' character, (a "dot
> > > directory"). In this case the configuration files should not start with the '.'
> > > character.
> > >
> > > I have no idea if we comply, but this is a new requirement.
> >
> > I think we do. This is common sense anyway, most applications I've seen
> > do it that way.
>
> It is probably a good idea to mention this either on policy itself (just to
> remind people), or on the packaging guide and maintainers reference. This
> requirement is something the maintainers have to watch out for...
>
> Somehow, I just know we will have someone complaining of this FHS
> requirement soon.
If you ask... The problem with this requirement is that the path to such
configuration files is the responsibility of the upstream authors and not
of the distributors. Forcing the distributors to choose a name is
likely to lead to several FHS compliant systems using incompatible
names for such files which is against the goal of the FHS.
I would like to note that several programs create files or directories
with names lacking the leading '.' that the FHS require: ~/GNUstep,
~/Desktop, ~/lynx_bookmarks.html.
Of course, I consider the FHS proposal to be common sense.
Cheers
--
Bill. <ball...@debian.org>
Imagine a large red swirl here.
paddy
> On Tue, Oct 26, 2004 at 03:02:02PM -0500, Manoj Srivastava wrote:
> > 5)==
> >
> > User specific configuration files for applications are stored in the user's
> > home directory in a file that starts with the '.' character (a "dot file"). If
> > an application needs to create more than one dot file then they should be
> > placed in a subdirectory with a name starting with a '.' character, (a "dot
> > directory"). In this case the configuration files should not start with the '.'
> > character.
> >
> > I have no idea if we comply, but this is a new requirement.
>
> I think we do. This is common sense anyway, most applications I've seen
> do it that way.
what about ~/Desktop and friends?
Regards,
Paddy
Joey Hess
> On Wed, Oct 27, 2004 at 11:28:14AM +0200, Wouter Verhelst wrote:
> > On Tue, Oct 26, 2004 at 03:02:02PM -0500, Manoj Srivastava wrote:
> > > 5)==
> > >
> > > User specific configuration files for applications are stored in the user's
> > > home directory in a file that starts with the '.' character (a "dot file"). If
> > > an application needs to create more than one dot file then they should be
> > > placed in a subdirectory with a name starting with a '.' character, (a "dot
> > > directory"). In this case the configuration files should not start with the '.'
> > > character.
> > >
> > > I have no idea if we comply, but this is a new requirement.
> >
> > I think we do. This is common sense anyway, most applications I've seen
> > do it that way.
>
> what about ~/Desktop and friends?
I don't know if Desktop falls under the heading of being a configuration
file or directorty. Not that I much like that directory, but like
Maildir, it seems out of the scope of this FHS requirement.
--
see shy jo
Ron Johnson
Is ~/Desktop a "User specific configuration files for applications"?
Doesn't seem like it to me. It and ~/Maildir are data directories.
--
-----------------------------------------------------------------
Ron Johnson, Jr.
Jefferson, LA USA
PGP Key ID 8834C06B
"The United States is not a nation to which peace is a
necessity."
Grover Cleveland
Nikolai Prokoschenko
> home directory in a file that starts with the '.' character (a "dot file"). If
Speaking of which: there used to be some proposed addition to FHS about
re-locating all dot-files into ~/etc or some directory like that. Does
anybody know what happened to that? I'm aware of the problems (sharing
$HOME over several different machines etc.), but but I'll be glad if the
mess were out of $HOME.
--
Nikolai Prokoschenko
nik...@prokoschenko.de / Jabber: pro...@jabber.org
Stig Brautaset
> User specific configuration files [...]
> should be placed in a subdirectory with a name starting with a '.'
> I have no idea if we comply, but this is a new requirement.
Slrn, at least, litters $HOME with .jnewsrc-* files.
Then there is the various shells, of course...
Stig
Adrian 'Dagurashibanipal' von Bidder
> paddy wrote:
> > what about ~/Desktop and friends?
>
> I don't know if Desktop falls under the heading of being a configuration
> file or directorty. Not that I much like that directory, but like
> Maildir, it seems out of the scope of this FHS requirement.
Ok, this is obviously off-topic here, but I think it's well within the FHS's
competence to get rid of these...
+---
| Applications MUST NOT require or create any files and directories in the
| users' home directories except
| (i) data files explicitely requested by the user
| (ii) temporary backup and lock files which belong to a file as described
| in (i) and are in the same directory as the data file, and start with
| a dot.
| (iii) configuration files, a.k.a dotfiles.
+--
Or something like that. I really think my $HOME is my castle, and nobody
should mess with that. dotfiles I can accept, but ~/Mail and ~/Desktop are
annoying (and, in the case of ~/Mail, totally useless if I use a remote
IMAP mail server but my mailclient still insists on it :-( :-( :-(
greetings
-- vbi
--
Oops
Travis Crump
> On Wed, 2004-10-27 at 19:53 -0400, Joey Hess wrote:
>
>>paddy wrote:
>>
>>>On Wed, Oct 27, 2004 at 11:28:14AM +0200, Wouter Verhelst wrote:
>>>
>>>>On Tue, Oct 26, 2004 at 03:02:02PM -0500, Manoj Srivastava wrote:
>>>>
>>>>> 5)==
>>>>>
>>>>>User specific configuration files for applications are stored in the user's
>>>>>home directory in a file that starts with the '.' character (a "dot file"). If
>>>>>an application needs to create more than one dot file then they should be
>>>>>placed in a subdirectory with a name starting with a '.' character, (a "dot
>>>>>directory"). In this case the configuration files should not start with the '.'
>>>>>character.
>>>>>
>>>>> I have no idea if we comply, but this is a new requirement.
>>>>
>>>>I think we do. This is common sense anyway, most applications I've seen
>>>>do it that way.
>>>
>>>what about ~/Desktop and friends?
>>
>>I don't know if Desktop falls under the heading of being a configuration
>>file or directorty. Not that I much like that directory, but like
>>Maildir, it seems out of the scope of this FHS requirement.
>
>
> Is ~/Desktop a "User specific configuration files for applications"?
>
> Doesn't seem like it to me. It and ~/Maildir are data directories.
>
>
pretzalz@Pretzalz:~$ ll Desktop
lrwxrwxrwx 1 pretzalz pretzalz 29 Dec 30 2003 Desktop ->
/home/pretzalz/.gnome-desktop
Seems an almost implicit admission that Desktop is wrong. If I really
wanted that symlink I could make it myself. And I don't use it but I
thought .gnome-desktop/Desktop is where you configure via symlinks what
you want to show up on your desktop.
Nikita V. Youshchenko
> re-locating all dot-files into ~/etc or some directory like that. Does
> anybody know what happened to that? I'm aware of the problems (sharing
> $HOME over several different machines etc.), but but I'll be glad if the
> mess were out of $HOME.
I think there is little hope here.
There are too many apps out that treat home directory as a wastebasket, and
probably Linux/Unix itself will be obsoleted faster than all those.
Marcelo E. Magallon
> 5)==
>
> User specific configuration files for applications are stored in the
> user's home directory in a file that starts with the '.' character (a
> "dot file"). If an application needs to create more than one dot file
> then they should be placed in a subdirectory with a name starting
> with a '.' character, (a "dot directory"). In this case the
> configuration files should not start with the '.' character.
>
> I have no idea if we comply, but this is a new requirement.
Holy... and that's the area of FHS... how?
First, does every single package have to comply with this?
Off the top of my head:
* aspell stores user's dictionaries in ~/, and it store several
files per languaje.
* bash reads and writes a number of files in ~/ (.bash_profile,
.bashrc, .bash_history)
* there are several directories related to GNOME (at least ~/.gnome2
and ~/.gnome2_private)
* vim has ~/.vimrc, ~/.viminfo (configure IIRC), ~/.vim/
* Window Maker stores its configuration across several files and
directories under ~/GNUstep (configurable) (and no, I won't change
the default because it's configurable via an environment variable)
> So, we have a few minor things to tweak (/media, /srv, and the
> XF86Config stuff, and then we should be OK to move to FHS 2.3 in
> Etch.
Isn't the configuration file used by the X.org server called something
else? (It's rather silly to hardcode the name of a configuration file
used by a specific vendor)
Marcelo
Nikolai Prokoschenko
> > Speaking of which: there used to be some proposed addition to FHS about
> > re-locating all dot-files into ~/etc or some directory like that. Does
> > anybody know what happened to that? I'm aware of the problems (sharing
> > $HOME over several different machines etc.), but but I'll be glad if the
> > mess were out of $HOME.
> I think there is little hope here.
> There are too many apps out that treat home directory as a wastebasket, and
> probably Linux/Unix itself will be obsoleted faster than all those.
Most applications can be patched to use another directory for their cruft.
It's just the "legal" sutff I'm currently interested in, as as soon as it
is "recommended" by FHS, it can become a part of e.g. Debian Policy and
get enforced by patches.
--
Nikolai Prokoschenko
nik...@prokoschenko.de / Jabber: pro...@jabber.org
Frank Küster
> On Tue, Oct 26, 2004 at 03:02:02PM -0500, Manoj Srivastava wrote:
>
> > 5)==
> >
> > User specific configuration files for applications are stored in the
> > user's home directory in a file that starts with the '.' character (a
> > "dot file").
[...]
> Holy... and that's the area of FHS... how?
>
> First, does every single package have to comply with this?
>
> Off the top of my head:
>
> * aspell stores user's dictionaries in ~/, and it store several
> files per languaje.
These I wouldn't name "configuration files". They are data files
containing my personal input for later reuse. Although, indeed, it would
be nice to have them in a subdirectory.
> * bash reads and writes a number of files in ~/ (.bash_profile,
> .bashrc, .bash_history)
> * there are several directories related to GNOME (at least ~/.gnome2
> and ~/.gnome2_private)
> * vim has ~/.vimrc, ~/.viminfo (configure IIRC), ~/.vim/
They should probably use their own directory in the future. I think this
would really be a good idea.
> * Window Maker stores its configuration across several files and
> directories under ~/GNUstep (configurable) (and no, I won't change
> the default because it's configurable via an environment variable)
I was always annoyed by this, and it's not easy to find the solution in
the documentation (I only learned of the environment variable in this
thread). Why not change the default, when everybody can get back the
original buggy behavior by setting an environment variable?
Regards, Frank
--
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer
Manoj Srivastava
> On Thu, Oct 28, 2004 at 09:46:47PM +0400, Nikita V. Youshchenko wrote:
>> > Speaking of which: there used to be some proposed addition to FHS
>> > about re-locating all dot-files into ~/etc or some directory like
>> > that. Does anybody know what happened to that? I'm aware of the
>> > problems (sharing $HOME over several different machines etc.),
>> > but but I'll be glad if the mess were out of $HOME.
>> I think there is little hope here. There are too many apps out
>> that treat home directory as a wastebasket, and probably Linux/Unix
>> itself will be obsoleted faster than all those.
> Most applications can be patched to use another directory for their
> cruft. It's just the "legal" sutff I'm currently interested in, as
> as soon as it is "recommended" by FHS, it can become a part of
> e.g. Debian Policy and get enforced by patches.
Actually, if it is not common practice, it would probably mean
that Debian would not adopt FHS 2.3 fully, only bits of it, and
policy would then enshrine the current practice, and it would be even
harder to change things.
So, if you have patches ready, I suggest you get moving on
having them implemented, and not wait for policy to have to outlaw
your patch set.
manoj
--
Four thousand different MAGNATES, MOGULS & NABOBS are romping in my
gothic solarium!!
Manoj Srivastava <sriv...@debian.org> <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Andreas Rottmann
>> * Window Maker stores its configuration across several files and
>> directories under ~/GNUstep (configurable) (and no, I won't change
>> the default because it's configurable via an environment variable)
>
> I was always annoyed by this, and it's not easy to find the solution in
> the documentation (I only learned of the environment variable in this
> thread). Why not change the default, when everybody can get back the
> original buggy behavior by setting an environment variable?
>
Why not simply make it search for ~/GNUstep, and when that isn't
found, ~/.GNUstep or something like that - would retain full
compatibility.
Rotty
--
Andreas Rottmann | Rotty@ICQ | 118634484@ICQ | a.rot...@gmx.at
http://yi.org/rotty | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62
Any technology not indistinguishable from magic is insufficiently advanced.
-- Terry Pratchett
Marcelo E. Magallon
> Why not simply make it search for ~/GNUstep, and when that isn't
> found, ~/.GNUstep or something like that - would retain full
> compatibility.
With Debian, yes. With the rest of the world, no. You have to take
into account to that ~/ is not unusually a shared resource.
Marcelo E. Magallon
> > * bash reads and writes a number of files in ~/ (.bash_profile,
> > .bashrc, .bash_history)
> > * there are several directories related to GNOME (at least ~/.gnome2
> > and ~/.gnome2_private)
> > * vim has ~/.vimrc, ~/.viminfo (configure IIRC), ~/.vim/
>
> They should probably use their own directory in the future. I think
> this would really be a good idea.
I don't think so. It's a matter of interoperability. If the guys
writing the FHS don't care about this it's their problem, but I've
worked for many years in environments where my home is shared among
computers with different operating systems (e.g. Linux, IRIX, HP/UX and
Solaris), and the prospect of increasing complexity in order to
accommodate something like the FHS doesn't appeal to me. I _do_ split
things like .bash_profile across several files in ~/.bash/.
Nevertheless I know that bash reads ~/.bashrc; introducing something
that deviates from this on some platforms buys the user little benefit.
By the way, you can get rid of ~/.viminfo by adding n~/.vim/viminfo to
viminfo.
> > * Window Maker stores its configuration across several files and
> > directories under ~/GNUstep (configurable) (and no, I won't change
> > the default because it's configurable via an environment variable)
>
> I was always annoyed by this, and it's not easy to find the solution
> in the documentation (I only learned of the environment variable in
> this thread). Why not change the default, when everybody can get back
> the original buggy behavior by setting an environment variable?
It's in the manual page:
GNUSTEP_USER_ROOT
specifies the initial path for the Defaults
directory. "Defaults/" is appended to this variable to
determine the actual location of the databases. If
the varialbe is not set, it defaults to "~/GNUstep"
patches to improve wording or make it easier to understand (or for that
matter, to add a whole new section to the manpage if you think that's
the solution) are always welcomed.
I guess something like this would work:
if test -z "$GNUSTEP_USER_ROOT" ; then
if test -d "$HOME/GNUstep" ; then
GNUSTEP_USER_ROOT="$HOME/GNUstep"
else
GNUSTEP_USER_ROOT="$HOME/.GNUstep"
fi
but I have the same interoperatibility problem again. This deviates
from the upstream default behaviour.
Rolf Kutz
> Manoj Srivastava wrote:
> > an application needs to create more than one dot file then they should be
> > placed in a subdirectory with a name starting with a '.' character, (a "dot
> > directory"). In this case the configuration files should not start with the '.'
> > character.
> - zsh (.zcompdump, .zlogin, .zshenv, .zshrc)
- bash (.bashrc, .bash_profile)
- Rolf
Matt Zimmerman
> Note that new sarge installs should be basically /media compliant,
> although I don't know if we have every subdir the FHS may require in
> there. And we still have a /cdrom link to /media since some programs
> (like apt) have not transitioned.
I don't think anyone has mentioned the need for a transition on -deity.
It would be trivial to change the default, but it would also break existing
systems. It could possibly search a list of likely mount points, or read
fstab.
We could also transition existing systems to /media.
--
- mdz
--
To UNSUBSCRIBE, email to debian-pol...@lists.debian.org
Matt Zimmerman
> "Marcelo E. Magallon" <mmag...@debian.org> wrote:
> > * bash reads and writes a number of files in ~/ (.bash_profile,
> > .bashrc, .bash_history)
> > * there are several directories related to GNOME (at least ~/.gnome2
> > and ~/.gnome2_private)
> > * vim has ~/.vimrc, ~/.viminfo (configure IIRC), ~/.vim/
>
> They should probably use their own directory in the future. I think this
> would really be a good idea.
It would have been a good idea when these programs were being written.
It doesn't seem at all worthwhile to endure a transition of existing
software for the marginal aesthetic benefits.
--
- mdz
Marco d'Itri
> It would have been a good idea when these programs were being written.
> It doesn't seem at all worthwhile to endure a transition of existing
> software for the marginal aesthetic benefits.
Agreed. I see no point in even discussing this, considering that FHS
says "should" and not "must".
--
ciao, |
Marco | [9020 baWEaEGQpMwlw]