[gentoo-dev] gentoo vs. the FHS

[gentoo-dev] gentoo vs. the FHS

[aeriksson]

Hi all,

(I recently posted this stuff to-users, but there was no reply.
Hopefully -dev is the right place.)


How come gentoo doesn't follow the File Hierarcy Standard (FHS) more
closely? For example, there are provisions in FHS to use /var/cache
for stuff which applicatons can recreate if it doesn't exist (the the
administrator can purge the directory at will). Putting 
/usr/portage/distfiles/ there seems obvious to me. But having 
edb/world
in there (with all memory of your world configuations) seems not too 
smart.

What's the philosophy around this? Shouldn't edb live in e.g. 
/var/lib?

Cheers,
/Anders



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] gentoo vs. the FHS

[Stanislav Brabec]

There are other issues, too:

1)
/usr/libexec (should not exist, files should be moved to /usr/sbin
and/or /usr/lib)

2)
/mnt (is reserved for administrator, subdirectories not allowed, mount
point for removable media is not yet standardized, will probably be
/media)
http://bugs.freestandards.org/cgi-bin/bugzilla/show_bug.cgi?id=27

3)
/home/httpd (/home is reserved for users, service home is not yet
standardized, will probably be /srv, currently /var/lib or /var is used
in other distros, too)
Causes big problem on AFS or NFS /home systems (unable to emerge update
on client machines; unable to have two webservers in one network,
because they are sharing data).

4)
/usr/kde and /usr/qt (/usr should not have sub-trees, sub trees are
allowed in /opt, i. e. /opt/kde and /opt/kde).

4)
/usr/games should be a directory for binaries, not subtree, (i. e.
/usr/games/bin -> /usr/games, /usr/games/lib -> /usr/lib,
/usr/games/share -> /usr/share/games).

5)
/usr/X11R6/share is not in FHS (probably move --datadir to
/usr/X11R6/lib/X11)

Issues 1, 4 and 5 can "automagically" solve GNU-FHS:
ftp://ftp.penguin.cz/pub/users/utx/fhs/

-- 
Stanislav Brabec
http://www.penguin.cz/~utx

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] gentoo vs. the FHS

[Matt Chorman]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 23 September 2003 01:08 pm, Stanislav Brabec wrote:
<snip>
> 4)
> /usr/kde and /usr/qt (/usr should not have sub-trees, sub trees are
> allowed in /opt, i. e. /opt/kde and /opt/kde).
>
> 4)
> /usr/games should be a directory for binaries, not subtree, (i. e.
> /usr/games/bin -> /usr/games, /usr/games/lib -> /usr/lib,
> /usr/games/share -> /usr/share/games).
<snip>

I don't really have any opinion one way or the other on the rest of the 
points, but I for one personally *like* qt and kde where it is at. I also 
like the structure of having games under /usr. It makes sense, to me, on my 
system. They are logically placed. At this point, only binaries-pkgs I've 
installed are in opt (i.e. vmware, openoffice-bin, and ET). I like it this 
way - I can easily allow prelink to exclude *one* dir.. Whether or not it 
conforms to standards does not matter to me. It makes sense this way, and it 
works well - IMO. 

Optimizations from source and USE settings aside, the one thing I am *really* 
beginning to love are the layouts of gentoo's filesystem. [plea]Please please 
PLEASE don't mess with them too much.[/plea]

- -- 
Matt

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x7D81740A
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/cKx8ZosHVX2BdAoRAts3AJwKnxN4QKsEsMMjChMzmMEEn9nR1gCfWyCk
609ZfpnLi4Vq8GmDjuLf7ig=
=BSep
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] gentoo vs. the FHS

[Caleb Tennis]

On Tuesday 23 September 2003 03:08 pm, Stanislav Brabec wrote:
> There are other issues, too:

<snip>

I don't understand the logic behind blindly following a document like the FHS.  
If there are compelling reasons why a directory of installation path is 
incorrect, then it needs to be addressed.  However, I can tell you that 99% 
of Linux users have multiple directories underneath /mnt (cdrom, hd, 
usbhd...).  This is a violation of the FHS.

As far as I can tell, Gentoo only doesn't comply in areas where it made more 
sense for us to use something different.  If installing kde and qt into /opt 
is most important, why not symlink it there?

I guess I just fail to see the advantage of having an "FHS compliant" sticker 
on the proverbial box when it makes more sense to do things differently. And 
in some cases, it is only that way to support legacy users who are used to 
doing things a certain way.

I have yet to see an installation that is 100% FHS compliant.  I'd say that 
97% is pretty darn good. :)

Caleb


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] gentoo vs. the FHS

[dams]

Caleb Tennis <caleb@gentoo.org> said:

> On Tuesday 23 September 2003 03:08 pm, Stanislav Brabec wrote:
>> There are other issues, too:
>
> <snip>
>
> I don't understand the logic behind blindly following a document like the FHS.  

FHS is made so that f*cking proprietary application get well installed on every
distribution, so that they can sell more, and make the big linux actors (IBM
and co), more rich.

If you agree with this way to let linux go forward (I have no opinion on that),
then be FHS compliant. It's certain that being FHS compliant is a plus when
dealing with proprietary software companies.

> If there are compelling reasons why a directory of installation path is 
> incorrect, then it needs to be addressed.  However, I can tell you that 99% 
> of Linux users have multiple directories underneath /mnt (cdrom, hd, 
> usbhd...).  This is a violation of the FHS.

-- 
dams

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] gentoo vs. the FHS

[Luke-Jr]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 23 September 2003 10:12 pm, dams@idm.fr wrote:
> FHS is made so that f*cking proprietary application get well installed on
> every distribution, so that they can sell more, and make the big linux
> actors (IBM and co), more rich.
Proprietary applications should not exist in the first place, AFAIC. If this 
is the purpose of the FHS, then I'm all for non-compliance! :)
>
> If you agree with this way to let linux go forward (I have no opinion on
> that), then be FHS compliant. It's certain that being FHS compliant is a
> plus when dealing with proprietary software companies.
Would we want proprietary software companies to maintain their own ebuilds in 
the portage tree anyway? I'd consider many open source project developers 
better qualified for that before a proprietary developer. Therefore, seeing 
as all the proprietary ebuilds are likely to be maintained outside of the 
company creating them anyway, do we need to deal with them at all (except in 
crazy EULA cases like Id, of course)?
- -- 
Luke-Jr
Developer, Gentoo Linux
http://www.gentoo.org/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/cNNBZl/BHdU+lYMRAnFyAJ9TXlhxdscZJtBNvvanzdSg5+X8hQCeN5/r
xrnOZ5QH2FjdMHwZ7mOzwI0=
=l1FW
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] gentoo vs. the FHS

[William Kenworthy]

As someone who works with a number of different OS's daily, from solaris
to various flavours of linux - the FHS and standards compliance is a
godsend.  The FHS has a few warts, and slavish compliance with it is not
desired, but generally, it is a "good thing".  Just because commercial
apps use it, doesnt mean its bad for everyone else, they just benefit
too.

BillK

On Wed, 2003-09-24 at 07:11, Luke-Jr wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Tuesday 23 September 2003 10:12 pm, dams@idm.fr wrote:
> > FHS is made so that f*cking proprietary application get well installed on



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] gentoo vs. the FHS

[Daniel Robbins]

[-- Attachment #1: Type: text/plain, Size: 469 bytes --]

On Tue, 2003-09-23 at 18:21, William Kenworthy wrote:
> As someone who works with a number of different OS's daily, from solaris
> to various flavours of linux - the FHS and standards compliance is a
> godsend.  The FHS has a few warts, and slavish compliance with it is not
> desired, but generally, it is a "good thing".  Just because commercial
> apps use it, doesnt mean its bad for everyone else, they just benefit
> too.

Agreed.

Sincerely,

Daniel

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] gentoo vs. the FHS

[Sven Vermeulen]

[-- Attachment #1: Type: text/plain, Size: 1007 bytes --]

On Wed, Sep 24, 2003 at 08:21:14AM +0800, William Kenworthy wrote:
> As someone who works with a number of different OS's daily, from solaris
> to various flavours of linux - the FHS and standards compliance is a
> godsend.  The FHS has a few warts, and slavish compliance with it is not
> desired, but generally, it is a "good thing".  Just because commercial
> apps use it, doesnt mean its bad for everyone else, they just benefit
> too.

I totally agree. The FHS is not only a nice standard (even though I see why
some distributions don't follow it 100%) it also is a nice document to
explain users why and how a Linux system is structured. 

And it's not like the FHS is static, it has changed several times and with
good pro/con references they will change the standard accordingly.

Wkr,
	Sven Vermeulen

-- 
 ^__^   And Larry saw that it was Good.
 (oo)                                      Sven Vermeulen
 (__)   http://www.gentoo.org              Gentoo Documentation Project

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] gentoo vs. the FHS

[Kevin Lacquement]

On Wed, Sep 24, 2003 at 12:12:41AM +0200, dams@idm.fr wrote:

<snip>
> 
> FHS is made so that f*cking proprietary application get well installed on every
> distribution, so that they can sell more, and make the big linux actors (IBM
> and co), more rich.
> 
> If you agree with this way to let linux go forward (I have no opinion on that),
> then be FHS compliant. It's certain that being FHS compliant is a plus when
> dealing with proprietary software companies.

Of course, to make proprietary apps happy, Gentoo would also need to be
LSB-compliant.  And _that_ requires supporting RPMs, which I don't think we
want to do (see the GWN from April 1).

Cheers,
Kevin

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] gentoo vs. the FHS

[Sven Vermeulen]

[-- Attachment #1: Type: text/plain, Size: 798 bytes --]

On Tue, Sep 23, 2003 at 08:08:30PM -0500, Kevin Lacquement wrote:
> Of course, to make proprietary apps happy, Gentoo would also need to be
> LSB-compliant.  And _that_ requires supporting RPMs, which I don't think we
> want to do (see the GWN from April 1).

The LSB states that the distribution must support RPMs, but it doesn't say
how. You don't have to have an rpm-based distribution, you can very well have
a conversion that creates ebuilds from an RPM.

The only problem you would have are dependencies, and the LSB clearly defines
what dependencies are allowed in LSB-RPMs.

Wkr,
	Sven Vermeulen

-- 
 ^__^   And Larry saw that it was Good.
 (oo)                                      Sven Vermeulen
 (__)   http://www.gentoo.org              Gentoo Documentation Project

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] gentoo vs. the FHS

[Daniel Robbins]

[-- Attachment #1: Type: text/plain, Size: 699 bytes --]

On Tue, 2003-09-23 at 16:12, dams@idm.fr wrote:
> FHS is made so that f*cking proprietary application get well installed on every
> distribution, so that they can sell more, and make the big linux actors (IBM
> and co), more rich.
> 
> If you agree with this way to let linux go forward (I have no opinion on that),
> then be FHS compliant. It's certain that being FHS compliant is a plus when
> dealing with proprietary software companies.

I think you may be confusing FHS with LSB. FHS is actually a decent stab
at standardizing the filesystem hierarchy. However, it is not perfect
and cannot address every possible issue. But it is a good general
guideline.

Sincerely,

Daniel

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] gentoo vs. the FHS

[Paul de Vrieze]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 2826 bytes --]

On Tuesday 23 September 2003 22:08, Stanislav Brabec wrote:
> There are other issues, too:
>
> 1)
> /usr/libexec (should not exist, files should be moved to /usr/sbin
> and/or /usr/lib)
>
File bugs against the applications that do this. The files get there because 
the installation makefiles put them there. /usr/sbin is not good as they are 
not supposed to be run by users, but /usr/lib could be reasonable. But try to 
first ask upstream why the packages use libexec. Some might have good 
reasons, for others it solves the problem for others than gentoo.

> 2)
> /mnt (is reserved for administrator, subdirectories not allowed, mount
> point for removable media is not yet standardized, will probably be
> /media)
> http://bugs.freestandards.org/cgi-bin/bugzilla/show_bug.cgi?id=27

rmdir /mnt/*
and create the /media, or wait until the standard is there

>
> 3)
> /home/httpd (/home is reserved for users, service home is not yet
> standardized, will probably be /srv, currently /var/lib or /var is used
> in other distros, too)
> Causes big problem on AFS or NFS /home systems (unable to emerge update
> on client machines; unable to have two webservers in one network,
> because they are sharing data).
>

This is being addressed, and will go to /var as we cannot work with probably

> 4)
> /usr/kde and /usr/qt (/usr should not have sub-trees, sub trees are
> allowed in /opt, i. e. /opt/kde and /opt/kde).
>
/opt is binary only. We have qt and kde from source, and they are also not 
that well self-contained. If the FHS people create a good solution for this 
we will be happy to use it, but /usr is not an option as it stops the ability 
to have paralel versions.

> 4)
> /usr/games should be a directory for binaries, not subtree, (i. e.
> /usr/games/bin -> /usr/games, /usr/games/lib -> /usr/lib,
> /usr/games/share -> /usr/share/games).
>
> 5)
> /usr/X11R6/share is not in FHS (probably move --datadir to
> /usr/X11R6/lib/X11)

Unfortunatly things still need to work. People expect XFree to be installed 
where it allways installs. That includes /usr/X11R6/share

>
> Issues 1, 4 and 5 can "automagically" solve GNU-FHS:
> ftp://ftp.penguin.cz/pub/users/utx/fhs/

The main point of the distribution is to be maintainer friendly and before 
that to run well. This means that at some points we need to be flexible 
enough to create solutions that are not offered by the FHS. Especially when 
it does not offer good alternatives. That means that FHS compliance, while 
desirable allways comes second to the costs needed to be compliant. This is 
especially true in the many vague areas of the FHS (that even FHS zealots 
cannot agree on).

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] gentoo vs. the FHS

[splite-gentoo]

On Tue, Sep 23, 2003 at 11:26:36PM +0200, Paul de Vrieze wrote:
Content-Description: signed data
> On Tuesday 23 September 2003 22:08, Stanislav Brabec wrote:
> > /usr/X11R6/share is not in FHS (probably move --datadir to
> > /usr/X11R6/lib/X11)
> 
> Unfortunatly things still need to work. People expect XFree to be installed 
> where it allways installs. That includes /usr/X11R6/share

XFree86 doesn't create or install anything in /usr/X11R6/share.  OpenMotif
puts stuff there but shouldn't.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] gentoo vs. the FHS

[Stanislav Brabec]

V Út, 23. 09. 2003 v 23:26, Paul de Vrieze píše:
> On Tuesday 23 September 2003 22:08, Stanislav Brabec wrote:
> > There are other issues, too:
> >
> > 1)
> > /usr/libexec (should not exist, files should be moved to /usr/sbin
> > and/or /usr/lib)
> >
> File bugs against the applications that do this. The files get there because 
> the installation makefiles put them there. /usr/sbin is not good as they are 
> not supposed to be run by users, but /usr/lib could be reasonable. But try to 
> first ask upstream why the packages use libexec. Some might have good 
> reasons, for others it solves the problem for others than gentoo.

We can get rid /usr/libexec per system basis - change default in econf
--libexecdir=/usr/lib or use GNU-FHS module for autoconf based configure
scripts

Users are encouraged to add subdirectories in /usr/lib, for example:

./configure --libexecdir=/usr/lib/gnome-applets2 (or similar) for GNOME2
applet packages.

Redirection to /usr/sbin will occur only for inetd network services
(where /usr/lib is not nice) and similar thinks. GNU-FHS adds
--with-libexec-sbin

There were a long discussion on fhs-discuss about is 3 years ago.

For more see ftp://ftp.penguin.cz/pub/users/utx/fhs/README

> > 5)
> > /usr/X11R6/share is not in FHS (probably move --datadir to
> > /usr/X11R6/lib/X11)
> 
> Unfortunatly things still need to work. People expect XFree to be installed 
> where it allways installs. That includes /usr/X11R6/share

/usr/X11R6/share has never been part of XFree86.

-- 
Stanislav Brabec
http://www.penguin.cz/~utx

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] gentoo vs. the FHS

[Mike Frysinger]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 1409 bytes --]

On Tuesday 23 September 2003 16:08, Stanislav Brabec wrote:
> 3)
> /home/httpd (/home is reserved for users, service home is not yet
> standardized, will probably be /srv, currently /var/lib or /var is used
> in other distros, too)
> Causes big problem on AFS or NFS /home systems (unable to emerge update
> on client machines; unable to have two webservers in one network,
> because they are sharing data).

umm there is already work to redo this.  if you're interested, do some 
research on our web-apps herd.

> 4)
> /usr/kde and /usr/qt (/usr should not have sub-trees, sub trees are
> allowed in /opt, i. e. /opt/kde and /opt/kde).

afaik there are no plans to change this.  there have been a few bugs iirc 
about this, but all have been closed as WONTFIX or INVALID.  i'd suggest 
e-mailing kde@gentoo about it.

> 4)
> /usr/games should be a directory for binaries, not subtree, (i. e.
> /usr/games/bin -> /usr/games, /usr/games/lib -> /usr/lib,
> /usr/games/share -> /usr/share/games).

hmm the games setup (can be found in games.eclass) was created based upon 
(well what i thought was ...) FHS compliance ... i'll go back and review this 
again ...
if you want to see the current design, just read the games.eclass.

> 5)
> /usr/X11R6/share is not in FHS (probably move --datadir to
> /usr/X11R6/lib/X11)

should e-mail xfree@gentoo and/or file a bug ...

-mike

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] gentoo vs. the FHS

[Daniel Robbins]

[-- Attachment #1: Type: text/plain, Size: 479 bytes --]

On Tue, 2003-09-23 at 20:37, Mike Frysinger wrote:
> umm there is already work to redo this.  if you're interested, do some 
> research on our web-apps herd.

There is actually a very good GLEP written up about this, and it has
already been approved. See:

http://www.gentoo.org/proj/en/glep/glep-0011.html

The location we will be transitioning to is /var/www/localhost for
non-vhost stuff and /var/www/<fully-qualified-domain-name> for vhosts.

Regards,

Daniel

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] gentoo vs. the FHS

[Mike Frysinger]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 1123 bytes --]

On Tuesday 23 September 2003 22:37, Mike Frysinger wrote:
> > 4)
> > /usr/games should be a directory for binaries, not subtree, (i. e.
> > /usr/games/bin -> /usr/games, /usr/games/lib -> /usr/lib,
> > /usr/games/share -> /usr/share/games).
>
> hmm the games setup (can be found in games.eclass) was created based upon
> (well what i thought was ...) FHS compliance ... i'll go back and review
> this again ...
> if you want to see the current design, just read the games.eclass.

ok i reviewed FHS and decided to not change the way Gentoo does it.
to summarize, Gentoo puts binaries in /usr/games/bin and gaming related 
libraries in /usr/games/lib ... i dont know where you're getting this /usr/
games/share since no package should be using this ...
i dont like placing gaming related libraries into /usr/lib since nothing else 
in the system cares about games ...

in my mind it makes people's lives easier if they want to restrict games ... 
they only have to look at /usr/games/ and /usr/share/games/ rather than 
trying to track down specific files/directories in a huge list in /usr/lib/
-mike

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] gentoo vs. the FHS

[Luke-Jr]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monda
> ok i reviewed FHS and decided to not change the way Gentoo does it.
> to summarize, Gentoo puts binaries in /usr/games/bin and gaming related
> libraries in /usr/games/lib ... i dont know where you're getting this /usr/
> games/share since no package should be using this ...
> i dont like placing gaming related libraries into /usr/lib since nothing
> else in the system cares about games ...
>
> in my mind it makes people's lives easier if they want to restrict games
> ... they only have to look at /usr/games/ and /usr/share/games/ rather than
> trying to track down specific files/directories in a huge list in /usr/lib/
> -mike
Isn't it possible to change these directories anyway? If someone really wanted 
to change where their games go, couldn't they stick a games.eclass in their 
overlay to move it there?
- -- 
Luke-Jr
Developer, Gentoo Linux
http://www.gentoo.org/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/eE1rZl/BHdU+lYMRAuuDAJ9Ve+YBdo6iG8LKFbnqhFpUBGCmRgCeN0BK
3x0WQ5WJbNkR/yit2Xt7P5o=
=8rSk
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] gentoo vs. the FHS

[Stuart Herbert]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 1151 bytes --]

I was away when this thread started, and haven't caught up with all the posts 
yet, so apologies if this has already been said.

On Tuesday 23 September 2003 9:08 pm, Stanislav Brabec wrote:
> There are other issues, too:
> 3)
> /home/httpd (/home is reserved for users, service home is not yet
> standardized, will probably be /srv, currently /var/lib or /var is used
> in other distros, too)
> Causes big problem on AFS or NFS /home systems (unable to emerge update
> on client machines; unable to have two webservers in one network,
> because they are sharing data).

We're moving /home/httpd to be /var/www/localhost, and this will come in very 
shortly.

Best regards,
Stu
-- 
Stuart Herbert                                              stuart@gentoo.org
Gentoo Developer                                       http://www.gentoo.org/
Beta packages for download            http://dev.gentoo.org/~stuart/packages/
Come and meet me in March 2004                 http://www.phparch.com/cruise/

GnuGP key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]