1 |
On Thu, Aug 30, 2001 at 02:55:04PM -0400, Aron Griffis wrote: |
2 |
: > /usr "clean". This is a feature many people bring up as one of the |
3 |
: > better things in the Linux vs. *BSD. Might be worth a thought. |
4 |
: |
5 |
: This is interesting, but I don't think it applies to Gentoo. The NetBSD |
6 |
: packages collection is a set of software utilities and libraries which |
7 |
: have been ported to NetBSD. As such, they're sort of a layered product |
8 |
: that need to be separated from the base system in order to prevent |
9 |
: potential conflicts. (If I'm misunderstanding this, please tell me.) |
10 |
|
11 |
You've nailed half of it on the head. The other half is that this is a |
12 |
throwback to also separating what comes from the vendor and what |
13 |
"aftermarket" software the user installs (a la /usr/local -- /usr/pkg is |
14 |
just a NetBSDism for the same concept). |
15 |
|
16 |
But you're right, for Linux this is a non-issue. Everything that is a |
17 |
package developed and supported by a vendor goes under /usr. |
18 |
|
19 |
: To digress a bit, I think that /usr/pkg would make sense for a set of |
20 |
: packages that are maintained via a method separate from the base |
21 |
: distribution. For example, if Ximian were to offer a set of rpms to |
22 |
: install on Gentoo, they might install into /usr/pkg so as to prevent |
23 |
|
24 |
However, this breaks common logic and standard practice. I believe that |
25 |
according to the FHS this would still go somewhere under /opt. One can |
26 |
hope that the Ximian folks would do the right thing and install it under |
27 |
/opt/ximian instead of /opt/gnome. |
28 |
|
29 |
: > > (1) The FHS says: "This hierarchy is reserved for the X Window System, |
30 |
: > > version 11 release 6, and related files." IMHO that doesn't include |
31 |
: > > programs that are linked against the X libraries, just programs that |
32 |
: > > are delivered with the X distribution. |
33 |
: > |
34 |
: > This is a good reason for not installing in /usr/X11R6. |
35 |
: |
36 |
: Yes, and I think it's the reason most of our developers agree with. |
37 |
|
38 |
The problem is that this is vague, and I suspect intentionally so. The |
39 |
X-Open group's standard is that anything compiled for a specific version |
40 |
of X stays with that version of X. Okay, it may not be a standard, but |
41 |
it is recommended practice. |
42 |
|
43 |
If other distros put X files in /usr/local it's due to the fact that |
44 |
XFree86 is out-of-sync from the standard X distro. A hack to make it |
45 |
easy to upgrade an entire X11 tree and then include some stub |
46 |
libraries in order to keep from recompiling older binaries is not the |
47 |
correct solution (IMO). |
48 |
|
49 |
: > > (2) Consistency with other major distributions. Both Red Hat and Debian |
50 |
: > > install programs (even those linked against X libraries) in /usr. |
51 |
: > > (For the most part... Deviations seem to be primarily historical.) |
52 |
: > |
53 |
: > I don't think this weights in so much. We are pretty different from the |
54 |
: > other distributions and tries to do the stuff the way we think is best. |
55 |
: > This argument should (IMHO) only be used where it really doesn't matter |
56 |
: > to us. |
57 |
: |
58 |
: Consistency with other major distributions carries more weight in my |
59 |
: mind, primarily because I think it would be a shame if we fail to learn |
60 |
: from their experience. |
61 |
|
62 |
Please see my previous response. Personally, I'd rather do it the |
63 |
"correct" way. Currently, all the Linux standards bodies are accepting |
64 |
the Redhat way as the correct one. I don't think we should buy into |
65 |
that falicy. If we do, then stop working on portage and let's start |
66 |
cranking out RPMs. |
67 |
|
68 |
: I don't see Gnome and KDE fitting into that category, especially since |
69 |
: they are comprised of many different packages each (not one coherent |
70 |
: piece). |
71 |
|
72 |
However, GNOME and KDE are meant to be looked at as coherent |
73 |
environments that give the user the ability to install multiple |
74 |
components. For that reason alone, they do belong in /opt. It's no |
75 |
different than choosing not to install all of Mozilla's or StarOffice's |
76 |
components. |
77 |
|
78 |
--Jerry |
79 |
|
80 |
name: Jerry Alexandratos || Open-Source software isn't a |
81 |
phone: 703.599.6023 || matter of life or death... |
82 |
email: jerry@×××××××.org || ...It's much more important |
83 |
|| than that! |