1 |
tor 2001-08-30 klockan 21.31 skrev Aron Griffis: |
2 |
> Jerry A! wrote: [Thu Aug 30 2001, 04:25:12PM EDT] |
3 |
> > : To digress a bit, I think that /usr/pkg would make sense for a set of |
4 |
> > : packages that are maintained via a method separate from the base |
5 |
> > : distribution. For example, if Ximian were to offer a set of rpms to |
6 |
> > : install on Gentoo, they might install into /usr/pkg so as to prevent |
7 |
> > |
8 |
> > However, this breaks common logic and standard practice. I believe that |
9 |
> > according to the FHS this would still go somewhere under /opt. One can |
10 |
> > hope that the Ximian folks would do the right thing and install it under |
11 |
> > /opt/ximian instead of /opt/gnome. |
12 |
> |
13 |
> Agreed. My example was a poor attempt to present a case where /usr/pkg |
14 |
> might be justified on Gentoo. |
15 |
|
16 |
Hi! |
17 |
|
18 |
This was not a suggestion, more to throw in another aspect. This is |
19 |
truly not the "Linux"-way of doing it and I think the discussions about |
20 |
that our basesystem is installed in the same way as everything else (ie. |
21 |
through portage and not by unpacking the system-tarball). So this ruled |
22 |
out... |
23 |
|
24 |
I'm going to drop the /usr/X11R6-discussion as we all (at least from |
25 |
what I understood it agreed everything not X itself being moved into |
26 |
/usr). |
27 |
|
28 |
> > : Consistency with other major distributions carries more weight in my |
29 |
> > : mind, primarily because I think it would be a shame if we fail to learn |
30 |
> > : from their experience. |
31 |
|
32 |
I more see it that's what we are doing here :) hence the split in |
33 |
/opt/gnome, /opt/kde ... :) |
34 |
|
35 |
> That's not my point. I don't mind diverging from Red Hat's methods. |
36 |
> But Red Hat also approached this question once and decided to install in |
37 |
> /usr. It would be foolish of us to assume that they put no thought into |
38 |
> the matter. |
39 |
|
40 |
They have probably given this more thought. But I think the problem is |
41 |
bigger on RPM-based system. The RPM (or generally, a binary-based |
42 |
packagesystem) is going to have third party packages created by all |
43 |
kinds of people/companies/groups. It's much more convinient to just put |
44 |
everything in /usr. |
45 |
|
46 |
I really like the idea of having GNOME in /opt/gnome and KDE in |
47 |
/opt/KDE. I really don't like /usr/bin contain thousands of binaries. I |
48 |
don't however don't really like the idea of packages being put in |
49 |
different places depending on which USE-flags was used when building the |
50 |
package. |
51 |
|
52 |
> > However, GNOME and KDE are meant to be looked at as coherent |
53 |
> > environments that give the user the ability to install multiple |
54 |
> > components. For that reason alone, they do belong in /opt. It's no |
55 |
> > different than choosing not to install all of Mozilla's or |
56 |
> > StarOffice's components. |
57 |
> |
58 |
> It's quite different. Mozilla and StarOffice are distributed as |
59 |
> single coherent programs, consisting of multiple modules. Neither of |
60 |
> these programs split naturally; they are both designed to be run from |
61 |
> their own hierarchy (hence MOZILLA_FIVE_HOME). |
62 |
|
63 |
Not sure about KDE but GNOME has the GNOME_PATH env. variable for |
64 |
specifying where GNOME is installed. |
65 |
|
66 |
> Gnome and KDE are library frameworks that applications might or might |
67 |
> not link against, raising the question of whether the applications |
68 |
> should move around depending on how they're linked. Gnome and KDE |
69 |
> settle very well into the /usr hierarchy (simply by specifying |
70 |
> --prefix=/usr). |
71 |
|
72 |
If we fail to solve the issue about packages optionally linked against |
73 |
GNOME/KDE I think it would be better to install everything in /usr. |
74 |
|
75 |
Regards, |
76 |
Mikael Hallendal |
77 |
|
78 |
-- |
79 |
|
80 |
Mikael Hallendal |
81 |
Gentoo Linux Developer, Desktop Team Leader |
82 |
CodeFactory AB, Stockholm, Sweden |