Gentoo Archives: gentoo-dev

From: Luke Ravitch <luke@××××××××××.com>
To: gentoo-dev@g.o
Subject: Re: [gentoo-dev] Why the FHS can't be followed
Date: Tue, 02 Jul 2002 20:54:25
Message-Id: 20020703015424.GB3221@ogremage.dslxtreme.com
In Reply to: Re: [gentoo-dev] Why the FHS can't be followed by Jean-Michel Smith
1 On 2002-07-02 15:04, Jean-Michel Smith <jsmith@××××.com> wrote:
2 > This is a problem we're going to keep running into, perhaps more commonly as
3 > large, free(dom) office suites, new desktops like gnustep and enlightenment,
4 > etc. mature. Perhaps we should be looking for a more general solution,
5 > rather than making exceptions for gnome and KDE.
6
7 I think the /usr/X11R6 approach scales nicely for things like GNUstep
8 or maybe XFce (don't know much about XFce). I don't know that E
9 really calls for its own directory tree yet. If we think that makes
10 /usr/X11R6 too cluttered, we could always do something like
11 /usr/X11R6/desktops. However, I prefer /usr/X11R6/gnome,
12 /usr/X11R6/kde, /usr/X11R6/gnustep, etc.
13
14 > I mean, if we've decided the FHS is wrong on this particular point, why not
15 > make the fix more general and all-encompassing?
16
17 We (well, _I_) haven't totally decided that it's wrong. (Still
18 debating.) By my reading, putting X-based desktop environments (e.g,
19 Gnome and KDE) in their own trees under /usr/X11R6 is FHS compatible.
20 Adding a directory directly under /usr is clearly a violation.
21
22 > I would prefer to see /usr/X11R6 remain a relatively "pure" X tree (I never
23 > liked the way Mandrake dumped a lot of non-core 3rd party X apps into
24 > /usr/X11R6/bin, for example), and I do not think /usr/X11R6 offers a general
25
26 The X tree was never really meant to be "pure". Look at the whole
27 xmkmf thing. "Normal" X programs go in the /usr/X11R6 tree.
28
29 > solution. What about a big database or SAP application that has no GUI, but
30 > is monstrous and demanding of its own tree, yet for whatever reason doesn't
31 > belong in /opt?
32
33 Those seem like exactly why /opt exists. Gnome and KDE are
34 infrastructure, they aren't really "applications". And, since they
35 are in many ways extensions on X, I think it makes sense to put them
36 under the X tree. The home for monstrous _applications_ (like office
37 suites or database apps) that demand their own trees and are
38 self-contained (i.e., nothing depends on them) is /opt.
39
40 I only see an exception for things like Gnome and KDE. (Because, like
41 X, other applications depend on them.) And those can't pop up too
42 often. Also, we should avoid giving things their own directory tree
43 unless it's really, really justified. (The Stow fans are surely gonna
44 beat me up over that one ;-)
45
46 > I don't have any bright ideas on what the directory should be called, per se,
47 > and I'm sure someone will think of a more clever name than this, but if we're
48 > going to deviate from the FHS why not make it for just ONE directory, beneath
49 > which subdirectories for large, free package suites like KDE, Gnome,
50 > Enlightenment, etc could reside. Something like:
51 >
52 > /usr/sw/kde/2
53 > /usr/sw/kde/3
54 > /usr/sw/gnome/1
55 > /usr/sw/gnome/2
56 > /usr/sw/enlightenment/16
57 > /usr/sw/enlightenment/17
58 >
59 > and so on. (sw=software, not a very imaginative name. Perhaps the long
60 > version is better, e.g. /usr/software/kde/2, etc.)
61
62 The idea has merit, but I'm too concerned that this would encourage
63 putting too many things into /usr/software. Stow is fine in the
64 /usr/local tree for those who like it, but I don't think Gentoo should
65 embrace it (or something like it) for system packages (i.e., anything
66 in /usr except for /usr/local).
67
68 > In any event, the deviation from the FHS would be limited to one
69 > directory and more or less isolated from the rest of the filesystem
70 > tree. Indeed, given that the FHS doesn't consider the possibility
71 > of keeping around multiple versions of large software suites like
72 > KDE and Gnome (something which *should* be provided for, as that is
73 > in keeping with UNIX's tradition of allowing versioned libraries,
74 > etc. to coexist nicely), perhaps such a solution could be proposed
75 > as an amendment to the FHS.
76
77 Unix is traditionally good at handling multiple library versions, but
78 there hasn't been great support for multiple application versions.
79 (Various sysadmin-specific kludges exist.) I think that's okay. I
80 can run Gnome 1.4 apps under Gnome 2 with only one Gnome tree. But I
81 only have one version of each Gnome app. Good enough for me.
82
83 QT makes things stickier for a source-based distro because it requires
84 all that precompiling stuff. So, though it's not my absolute
85 favorite, I'd be okay with something like:
86
87 /usr
88 +--->X11R6
89 +--->gnome
90 | +--->1
91 | +--->2
92 +--->kde
93 +--->2
94 +--->3
95
96 Though I'd kinda prefer something like:
97
98 /usr
99 +--->X11R6
100 +--->gnome1
101 +--->gnome2
102 +--->kde2
103 +--->kde3
104
105 That way we don't have to type as many slashes ;-)
106
107 With only a couple versions of each desktop environment (or do people
108 still depend on KDE 1 apps?) and two, three, or four desktop
109 environments, that's quite manageable.
110
111 So I vote for one of the above to layouts. Picking the right one is a
112 matter of decided which gives the best breadth/depth ratio.
113
114 --
115 Luke

Replies

Subject Author
Re: [gentoo-dev] Why the FHS can't be followed Fuper <futurist@×××××××××××××××.com>