[gentoo-dev] Programs that depend on X libraries

[gentoo-dev] Programs that depend on X libraries

[Aron Griffis]

Hello,

There has been a minor debate on #gentoo regarding where to install
programs that depend on X libraries.  The trend in the ebuilds is
currently to install to /usr/X11R6.

I'd like to propose that programs should almost always install in /usr
rather than /usr/X11R6.  My reasons follow:

(1) The FHS says: "This hierarchy is reserved for the X Window System,
    version 11 release 6, and related files."  IMHO that doesn't include
    programs that are linked against the X libraries, just programs that
    are delivered with the X distribution.

(2) Consistency with other major distributions.  Both Red Hat and Debian
    install programs (even those linked against X libraries) in /usr.
    (For the most part... Deviations seem to be primarily historical.)

(3) Simplicity in the ebuilds.  Consider the following scenarios:

    * ebuild with multiple binaries, some of which link against X,
      others that don't.  Does the ebuild author split up the binaries?
      If so, this becomes confusing to both the ebuild author (who has
      to go through and distinguish one from the other) and to the
      end-user (who might expect both prog and xprog to live in the same
      location).

    * ebuild with binary that optionally links to X.  Does the ebuild
      author put conditionals in the ebuild to install in either
      /usr/X11R6 or /usr?  If so, this again creates a confusing
      situation for the end-user.

    In both of these cases, it's easier to install to /usr and not worry
    about either of the above.

(4) Potential to have multiple X distributions installed.  Say for
    instance that I like to have XFree86-3.3.6, XFree86-4.0.1, and
    Accelerated-X installed.  I might like to install these in
    hierarchies under /usr/XFree86-3.3.6, /usr/XFree86-4.0.1, and
    /usr/Accel-X, then create a symlink /usr/X11R6 that points to the
    tree I'm using at the moment.  All other technical concerns with
    this scheme aside, this at least creates a problem for ebuilds that
    like to install in /usr/X11R6.

Thanks,
Aron

Re: [gentoo-dev] Programs that depend on X libraries

[Mikael Hallendal]

ons 2001-08-29 klockan 19.01 skrev Aron Griffis:
> Hello,

Hi!

> I'd like to propose that programs should almost always install in /usr
> rather than /usr/X11R6.  My reasons follow:

I'm not really sure where I stand in this discussion yet :)
(I think I agree with you though)

First of all, I want to enlighten people not used to BSD that there is
another way. BSDs (at least NetBSD, think the others does this too)
installes everything not in the base-system in it's own directory
(/usr/pkg/ on NetBSD). This is a nice solution IMHO since it keeps /usr
"clean". This is a feature many people bring up as one of the better
things in the Linux vs. *BSD. Might be worth a thought.

> (1) The FHS says: "This hierarchy is reserved for the X Window System,
>     version 11 release 6, and related files."  IMHO that doesn't include
>     programs that are linked against the X libraries, just programs that
>     are delivered with the X distribution.

This is a good reason for not installing in /usr/X11R6.
 
> (2) Consistency with other major distributions.  Both Red Hat and Debian
>     install programs (even those linked against X libraries) in /usr.
>     (For the most part... Deviations seem to be primarily historical.)

I don't think this weights in so much. We are pretty different from the
other distributions and tries to do the stuff the way we think is best.
This argument should (IMHO) only be used where it really doesn't matter
to us.
 
> (3) Simplicity in the ebuilds.  Consider the following scenarios:
> 
>     * ebuild with multiple binaries, some of which link against X,
>       others that don't.  Does the ebuild author split up the binaries?
>       If so, this becomes confusing to both the ebuild author (who has
>       to go through and distinguish one from the other) and to the
>       end-user (who might expect both prog and xprog to live in the same
>       location).
> 
>     * ebuild with binary that optionally links to X.  Does the ebuild
>       author put conditionals in the ebuild to install in either
>       /usr/X11R6 or /usr?  If so, this again creates a confusing
>       situation for the end-user.
> 
>     In both of these cases, it's easier to install to /usr and not worry
>     about either of the above.

Yes, this is the reason I think is worse the most. I really don't like
the install-in-different-paths-depending-on-whats-it-linked-against.

This is the same with GNOME. Like XChat, if it's compiled with
GNOME-support it's installed in /opt/gnome and if it's not it's
installed in /usr/X11R6 (and with current setup, it should be added a
text-only version which should go into /usr).

Another issue about this is even worse. How about libraries?
gdk-pixbuf can optionally be built with GNOME-support. Currently (to
follow current guidelines) I install it in /opt/gnome if it's built with
GNOME-support and in /usr/X11R6 otherwise.
This is _NOT_ good because I think ebuild-writers shouls be able to know
in which prefix other packages are installed in (especially libs because
they might have to give that as an option to there packages).

> (4) Potential to have multiple X distributions installed.  Say for
>     instance that I like to have XFree86-3.3.6, XFree86-4.0.1, and
>     Accelerated-X installed.  I might like to install these in
>     hierarchies under /usr/XFree86-3.3.6, /usr/XFree86-4.0.1, and
>     /usr/Accel-X, then create a symlink /usr/X11R6 that points to the
>     tree I'm using at the moment.  All other technical concerns with
>     this scheme aside, this at least creates a problem for ebuilds that
>     like to install in /usr/X11R6.

This however is (I think) something that speeks for actually installing
into /usr/X11R6. Because an app compiled against XFree86 3.3.6 or
Accel-X might not work without recompile against XFree86 4.0.1. (I'm not
sure about this).

So if we by changing the /usr/X11R6-link break lots of packages
installed it's better if they are installed in the old path so they
won't be found or something.

Regards,
  Mikael Hallendal

-- 

Mikael Hallendal
Gentoo Linux Developer, Desktop Team Leader
CodeFactory AB, Stockholm, Sweden

Re: [gentoo-dev] Programs that depend on X libraries

[Daniel Robbins]

On Wed, Aug 29, 2001 at 03:01:52PM -0400, Aron Griffis wrote:
> Hello,
> 
> There has been a minor debate on #gentoo regarding where to install
> programs that depend on X libraries.  The trend in the ebuilds is
> currently to install to /usr/X11R6.

I'm leaning towards using /usr unconditionally as you suggest; it'll
simplify our existing ebuilds and make things more consistent.

Best Regards,

-- 
Daniel Robbins					<drobbins@gentoo.org>
Chief Architect/President			http://www.gentoo.org 
Gentoo Technologies, Inc.			

Re: [gentoo-dev] Programs that depend on X libraries

[Ben Lutgens]

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

On Wed, Aug 29, 2001 at 03:01:52PM -0400, Aron Griffis wrote:
>(1) The FHS says: "This hierarchy is reserved for the X Window System,
>    version 11 release 6, and related files."  IMHO that doesn't include
>    programs that are linked against the X libraries, just programs that
>    are delivered with the X distribution.

This was my interpretation as well. I agree with --prefix=/usr

>
>(2) Consistency with other major distributions.  Both Red Hat and Debian
>    install programs (even those linked against X libraries) in /usr.
>    (For the most part... Deviations seem to be primarily historical.)
>
>(3) Simplicity in the ebuilds.  Consider the following scenarios:
>
>    * ebuild with multiple binaries, some of which link against X,
>      others that don't.  Does the ebuild author split up the binaries?
>      If so, this becomes confusing to both the ebuild author (who has
>      to go through and distinguish one from the other) and to the
>      end-user (who might expect both prog and xprog to live in the same
>      location).
>
>    * ebuild with binary that optionally links to X.  Does the ebuild
>      author put conditionals in the ebuild to install in either
>      /usr/X11R6 or /usr?  If so, this again creates a confusing
>      situation for the end-user.
>
>    In both of these cases, it's easier to install to /usr and not worry
>    about either of the above.
>
>(4) Potential to have multiple X distributions installed.  Say for
>    instance that I like to have XFree86-3.3.6, XFree86-4.0.1, and
>    Accelerated-X installed.  I might like to install these in
>    hierarchies under /usr/XFree86-3.3.6, /usr/XFree86-4.0.1, and
>    /usr/Accel-X, then create a symlink /usr/X11R6 that points to the
>    tree I'm using at the moment.  All other technical concerns with
>    this scheme aside, this at least creates a problem for ebuilds that
>    like to install in /usr/X11R6.
>
>Thanks,
>Aron
>
>_______________________________________________
>gentoo-dev mailing list
>gentoo-dev@cvs.gentoo.org
>http://cvs.gentoo.org/mailman/listinfo/gentoo-dev
>

-- 
-------------------------------------------------------------------------------
Ben Lutgens
Gentoo Linux Developer and Anti-Okra Advocate

http://www.gentoo.org

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

Re: [gentoo-dev] Programs that depend on X libraries

[Mikael Hallendal]

tor 2001-08-30 klockan 00.05 skrev Daniel Robbins:
> On Wed, Aug 29, 2001 at 03:01:52PM -0400, Aron Griffis wrote:
> > Hello,
> > 
> > There has been a minor debate on #gentoo regarding where to install
> > programs that depend on X libraries.  The trend in the ebuilds is
> > currently to install to /usr/X11R6.
> 
> I'm leaning towards using /usr unconditionally as you suggest; it'll
> simplify our existing ebuilds and make things more consistent.

What about programs that optionally install in /opt/kde or /opt/gnome?
and especially libs that optionally support gnome or kde.

Regards,
  Mikael Hallendal

-- 

Mikael Hallendal
Gentoo Linux Developer, Desktop Team Leader
CodeFactory AB, Stockholm, Sweden

Re: [gentoo-dev] Programs that depend on X libraries

[Peter Kadau]

hi !

> > I'd like to propose that programs should almost always install in /usr
> > rather than /usr/X11R6.  My reasons follow:

> First of all, I want to enlighten people not used to BSD that there is
> another way. BSDs (at least NetBSD, think the others does this too)
> installes everything not in the base-system in it's own directory
> (/usr/pkg/ on NetBSD). This is a nice solution IMHO since it keeps /usr
> "clean".

imho, just put everything in /usr, unless you _want_
different versions/flavours of the same program
 
> > (3) Simplicity in the ebuilds.  Consider the following scenarios:

> Yes, this is the reason I think is worse the most. I really don't like
> the install-in-different-paths-depending-on-whats-it-linked-against.
> 
> This is the same with GNOME. Like XChat, if it's compiled  

yep, and i'm thinking about cdrdao here.
i really would like to forget about the /opt -stuff,
but i assume it has to be retained since FHS says so.

> Regards,
>   Mikael Hallendal

ciao
peter

-----------------------------------------------------------------
Peter Kadau <peterdotkadauatwebdotde>

"Why program by hand in five days what you can
 spend five years of your life automating ?"
-----------------------------------------------------------------
______________________________________________________________________________
Sie surfen im Internet statt im Meer? Selbst schuld!
Auf zum Strand: http://lastminute.de/?PP=1-0-100-105-1

Re: [gentoo-dev] Programs that depend on X libraries

[Aron Griffis]

Hi Mikael,

Mikael Hallendal wrote:	[Wed Aug 29 2001, 08:27:00PM EDT]
> First of all, I want to enlighten people not used to BSD that there is
> another way. BSDs (at least NetBSD, think the others does this too)
> installes everything not in the base-system in it's own directory
> (/usr/pkg/ on NetBSD). This is a nice solution IMHO since it keeps
> /usr "clean". This is a feature many people bring up as one of the
> better things in the Linux vs. *BSD. Might be worth a thought.

This is interesting, but I don't think it applies to Gentoo.  The NetBSD
packages collection is a set of software utilities and libraries which
have been ported to NetBSD.  As such, they're sort of a layered product
that need to be separated from the base system in order to prevent
potential conflicts.  (If I'm misunderstanding this, please tell me.)

That's not what we're dealing with in Gentoo.  There is no separation of
the "base system" from the "other packages", because the ebuilds
comprise a single collection of packages that make up the "base system".
As such, I don't think the /usr/pkg hierarchy makes sense for Gentoo.

To digress a bit, I think that /usr/pkg would make sense for a set of
packages that are maintained via a method separate from the base
distribution.  For example, if Ximian were to offer a set of rpms to
install on Gentoo, they might install into /usr/pkg so as to prevent
conflicts with the Portage-controlled directories.  I only bring this up
as a speculative situation in which /usr/pkg would make sense on Gentoo,
not because I want to open a discussion about rpms or Ximian!  :-)

> > (1) The FHS says: "This hierarchy is reserved for the X Window System,
> >     version 11 release 6, and related files."  IMHO that doesn't include
> >     programs that are linked against the X libraries, just programs that
> >     are delivered with the X distribution.
> 
> This is a good reason for not installing in /usr/X11R6.

Yes, and I think it's the reason most of our developers agree with.

> > (2) Consistency with other major distributions.  Both Red Hat and Debian
> >     install programs (even those linked against X libraries) in /usr.
> >     (For the most part... Deviations seem to be primarily historical.)
> 
> I don't think this weights in so much. We are pretty different from the
> other distributions and tries to do the stuff the way we think is best.
> This argument should (IMHO) only be used where it really doesn't matter
> to us.

Consistency with other major distributions carries more weight in my
mind, primarily because I think it would be a shame if we fail to learn
from their experience.

However I have a strong appreciation for the Gentoo developers' desire
to innovate, and to break nonsensical practices held to by other
distributions.  I think that's a strength of Gentoo that can carry us
a long way.  For that reason we have discussions like this one...

> > (3) Simplicity in the ebuilds.  Consider the following scenarios:
> > 
> >     * ebuild with multiple binaries, some of which link against X,
> >       others that don't.  Does the ebuild author split up the binaries?
> >       If so, this becomes confusing to both the ebuild author (who has
> >       to go through and distinguish one from the other) and to the
> >       end-user (who might expect both prog and xprog to live in the same
> >       location).
> > 
> >     * ebuild with binary that optionally links to X.  Does the ebuild
> >       author put conditionals in the ebuild to install in either
> >       /usr/X11R6 or /usr?  If so, this again creates a confusing
> >       situation for the end-user.
> > 
> >     In both of these cases, it's easier to install to /usr and not worry
> >     about either of the above.
> 
> Yes, this is the reason I think is worse the most. I really don't like
> the install-in-different-paths-depending-on-whats-it-linked-against.
> 
> This is the same with GNOME. Like XChat, if it's compiled with
> GNOME-support it's installed in /opt/gnome and if it's not it's
> installed in /usr/X11R6 (and with current setup, it should be added a
> text-only version which should go into /usr).
> 
> Another issue about this is even worse. How about libraries?
> gdk-pixbuf can optionally be built with GNOME-support. Currently (to
> follow current guidelines) I install it in /opt/gnome if it's built with
> GNOME-support and in /usr/X11R6 otherwise.
> This is _NOT_ good because I think ebuild-writers shouls be able to know
> in which prefix other packages are installed in (especially libs because
> they might have to give that as an option to there packages).

Yes, chaining on your reasoning here, I think that /opt/gnome and
/opt/kde should disappear, and be integrated into /usr.  I personally
think that they are another instance of the /usr/X11R6 problem.  The
only part that is different is the FHS.

The FHS defines /opt as "reserved for the installation of add-on
application software packages".  Those packages can be either
locally-installed or distribution-installed (made evident by the
following quote).

    The minor restrictions on distributions using /opt are necessary
    because conflicts are possible between distribution-installed and
    locally-installed software, especially in the case of fixed
    pathnames found in some binary software.

My interpretation of the FHS, with regard to /opt, is that it should be
the home of binary packages that are installed as a single coherent
piece.  For example, WordPerfect, Acroread, StarOffice, Netscape,
Mozilla(?), VMware, Quake, etc.

I don't see Gnome and KDE fitting into that category, especially since
they are comprised of many different packages each (not one coherent
piece).

> > (4) Potential to have multiple X distributions installed.  Say for
> >     instance that I like to have XFree86-3.3.6, XFree86-4.0.1, and
> >     Accelerated-X installed.  I might like to install these in
> >     hierarchies under /usr/XFree86-3.3.6, /usr/XFree86-4.0.1, and
> >     /usr/Accel-X, then create a symlink /usr/X11R6 that points to the
> >     tree I'm using at the moment.  All other technical concerns with
> >     this scheme aside, this at least creates a problem for ebuilds that
> >     like to install in /usr/X11R6.
> 
> This however is (I think) something that speeks for actually installing
> into /usr/X11R6. Because an app compiled against XFree86 3.3.6 or
> Accel-X might not work without recompile against XFree86 4.0.1. (I'm not
> sure about this).

Yeah, I think this is the easiest point to disagree on, and probably the
weakest in the group.  I'll just leave it out.  :-)

Aron

Re: [gentoo-dev] Programs that depend on X libraries

[Jerry A!]

On Thu, Aug 30, 2001 at 02:55:04PM -0400, Aron Griffis wrote:
: > /usr "clean". This is a feature many people bring up as one of the
: > better things in the Linux vs. *BSD. Might be worth a thought.
:
: This is interesting, but I don't think it applies to Gentoo.  The NetBSD
: packages collection is a set of software utilities and libraries which
: have been ported to NetBSD.  As such, they're sort of a layered product
: that need to be separated from the base system in order to prevent
: potential conflicts.  (If I'm misunderstanding this, please tell me.)

You've nailed half of it on the head.  The other half is that this is a
throwback to also separating what comes from the vendor and what
"aftermarket" software the user installs (a la /usr/local -- /usr/pkg is
just a NetBSDism for the same concept).

But you're right, for Linux this is a non-issue.  Everything that is a
package developed and supported by a vendor goes under /usr.

: To digress a bit, I think that /usr/pkg would make sense for a set of
: packages that are maintained via a method separate from the base
: distribution.  For example, if Ximian were to offer a set of rpms to
: install on Gentoo, they might install into /usr/pkg so as to prevent

However, this breaks common logic and standard practice.  I believe that
according to the FHS this would still go somewhere under /opt.  One can
hope that the Ximian folks would do the right thing and install it under
/opt/ximian instead of /opt/gnome.

: > > (1) The FHS says: "This hierarchy is reserved for the X Window System,
: > >     version 11 release 6, and related files."  IMHO that doesn't include
: > >     programs that are linked against the X libraries, just programs that
: > >     are delivered with the X distribution.
: >
: > This is a good reason for not installing in /usr/X11R6.
:
: Yes, and I think it's the reason most of our developers agree with.

The problem is that this is vague, and I suspect intentionally so.  The
X-Open group's standard is that anything compiled for a specific version
of X stays with that version of X.  Okay, it may not be a standard, but
it is recommended practice.

If other distros put X files in /usr/local it's due to the fact that
XFree86 is out-of-sync from the standard X distro.  A hack to make it
easy to upgrade an entire X11 tree and then include some stub
libraries in order to keep from recompiling older binaries is not the
correct solution (IMO).

: > > (2) Consistency with other major distributions.  Both Red Hat and Debian
: > >     install programs (even those linked against X libraries) in /usr.
: > >     (For the most part... Deviations seem to be primarily historical.)
: >
: > I don't think this weights in so much. We are pretty different from the
: > other distributions and tries to do the stuff the way we think is best.
: > This argument should (IMHO) only be used where it really doesn't matter
: > to us.
:
: Consistency with other major distributions carries more weight in my
: mind, primarily because I think it would be a shame if we fail to learn
: from their experience.

Please see my previous response.  Personally, I'd rather do it the
"correct" way.  Currently, all the Linux standards bodies are accepting
the Redhat way as the correct one.  I don't think we should buy into
that falicy.  If we do, then stop working on portage and let's start
cranking out RPMs.

: I don't see Gnome and KDE fitting into that category, especially since
: they are comprised of many different packages each (not one coherent
: piece).

However, GNOME and KDE are meant to be looked at as coherent
environments that give the user the ability to install multiple
components.  For that reason alone, they do belong in /opt.  It's no
different than choosing not to install all of Mozilla's or StarOffice's
components.

        --Jerry

name:  Jerry Alexandratos         ||  Open-Source software isn't a
phone: 703.599.6023               ||  matter of life or death...
email: jerry@thehutt.org          ||  ...It's much more important
                                  ||  than that!

Re: [gentoo-dev] Programs that depend on X libraries

[Aron Griffis]

Jerry A! wrote:	[Thu Aug 30 2001, 04:25:12PM EDT]
> : To digress a bit, I think that /usr/pkg would make sense for a set of
> : packages that are maintained via a method separate from the base
> : distribution.  For example, if Ximian were to offer a set of rpms to
> : install on Gentoo, they might install into /usr/pkg so as to prevent
> 
> However, this breaks common logic and standard practice.  I believe that
> according to the FHS this would still go somewhere under /opt.  One can
> hope that the Ximian folks would do the right thing and install it under
> /opt/ximian instead of /opt/gnome.

Agreed.  My example was a poor attempt to present a case where /usr/pkg
might be justified on Gentoo.

> : > > (1) The FHS says: "This hierarchy is reserved for the X Window System,
> : > >     version 11 release 6, and related files."  IMHO that doesn't include
> : > >     programs that are linked against the X libraries, just programs that
> : > >     are delivered with the X distribution.
> 
> The problem is that this is vague, and I suspect intentionally so.  The
> X-Open group's standard is that anything compiled for a specific version
> of X stays with that version of X.  Okay, it may not be a standard, but
> it is recommended practice.

Are you of the opinion that binaries linked to X libraries should live
in /usr/X11R6?

How does this work with, for example, the programs in /opt?  Most of
them will rely on X libraries, so they aren't "staying with that version
of X."

> If other distros put X files in /usr/local it's due to the fact that

Do you mean /usr?

> XFree86 is out-of-sync from the standard X distro.  A hack to make it
> easy to upgrade an entire X11 tree and then include some stub
> libraries in order to keep from recompiling older binaries is not the
> correct solution (IMO).

Why do you consider this a hack?  Including multiple versions of
libraries for the sake of binary compatibility makes sense.  As programs
are recompiled, they will be linked against the new X libraries, and
eventually it's possible to phase out the old libraries altogether.

> : Consistency with other major distributions carries more weight in my
> : mind, primarily because I think it would be a shame if we fail to learn
> : from their experience.
> 
> Please see my previous response.  Personally, I'd rather do it the
> "correct" way.  Currently, all the Linux standards bodies are accepting
> the Redhat way as the correct one.  I don't think we should buy into
> that falicy.  

That's not my point.  I don't mind diverging from Red Hat's methods.
But Red Hat also approached this question once and decided to install in
/usr.  It would be foolish of us to assume that they put no thought into
the matter.

> If we do, then stop working on portage and let's start
> cranking out RPMs.

That's a different topic, but I'll make one comment.  I have personally
created 300 or so rpms, including a complete distribution of Gnome for
Tru64 UNIX.  With that in mind, I have found the switch to ebuilds to be
a refreshing experience.  :-)

That said, I think there are some things the emerge system can learn
from rpms.  (/me ducks the rotten tomatoes.)  In all sincerity, building
and installing ebuilds in /tmp/portage as a non-privileged user is
a feature that emerge needs.

> : I don't see Gnome and KDE fitting into that category, especially since
> : they are comprised of many different packages each (not one coherent
> : piece).
> 
> However, GNOME and KDE are meant to be looked at as coherent
> environments that give the user the ability to install multiple
> components.  For that reason alone, they do belong in /opt.  It's no
> different than choosing not to install all of Mozilla's or
> StarOffice's components.

It's quite different.  Mozilla and StarOffice are distributed as
single coherent programs, consisting of multiple modules.  Neither of
these programs split naturally; they are both designed to be run from
their own hierarchy (hence MOZILLA_FIVE_HOME).

Gnome and KDE are library frameworks that applications might or might
not link against, raising the question of whether the applications
should move around depending on how they're linked.  Gnome and KDE
settle very well into the /usr hierarchy (simply by specifying
--prefix=/usr).

Aron

Re: [gentoo-dev] Programs that depend on X libraries

[Mikael Hallendal]

tor 2001-08-30 klockan 21.31 skrev Aron Griffis:
> Jerry A! wrote:	[Thu Aug 30 2001, 04:25:12PM EDT]
> > : To digress a bit, I think that /usr/pkg would make sense for a set of
> > : packages that are maintained via a method separate from the base
> > : distribution.  For example, if Ximian were to offer a set of rpms to
> > : install on Gentoo, they might install into /usr/pkg so as to prevent
> > 
> > However, this breaks common logic and standard practice.  I believe that
> > according to the FHS this would still go somewhere under /opt.  One can
> > hope that the Ximian folks would do the right thing and install it under
> > /opt/ximian instead of /opt/gnome.
> 
> Agreed.  My example was a poor attempt to present a case where /usr/pkg
> might be justified on Gentoo.

Hi!

This was not a suggestion, more to throw in another aspect. This is
truly not the "Linux"-way of doing it and I think the discussions about
that our basesystem is installed in the same way as everything else (ie.
through portage and not by unpacking the system-tarball). So this ruled
out...

I'm going to drop the /usr/X11R6-discussion as we all (at least from
what I understood it agreed everything not X itself being moved into
/usr).

> > : Consistency with other major distributions carries more weight in my
> > : mind, primarily because I think it would be a shame if we fail to learn
> > : from their experience.

I more see it that's what we are doing here :) hence the split in
/opt/gnome, /opt/kde ... :)

> That's not my point.  I don't mind diverging from Red Hat's methods.
> But Red Hat also approached this question once and decided to install in
> /usr.  It would be foolish of us to assume that they put no thought into
> the matter.

They have probably given this more thought. But I think the problem is
bigger on RPM-based system. The RPM (or generally, a binary-based
packagesystem) is going to have third party packages created by all
kinds of people/companies/groups. It's much more convinient to just put
everything in /usr.

I really like the idea of having GNOME in /opt/gnome and KDE in
/opt/KDE. I really don't like /usr/bin contain thousands of binaries. I
don't however don't really like the idea of packages being put in
different places depending on which USE-flags was used when building the
package.

> > However, GNOME and KDE are meant to be looked at as coherent
> > environments that give the user the ability to install multiple
> > components.  For that reason alone, they do belong in /opt.  It's no
> > different than choosing not to install all of Mozilla's or
> > StarOffice's components.
> 
> It's quite different.  Mozilla and StarOffice are distributed as
> single coherent programs, consisting of multiple modules.  Neither of
> these programs split naturally; they are both designed to be run from
> their own hierarchy (hence MOZILLA_FIVE_HOME).

Not sure about KDE but GNOME has the GNOME_PATH env. variable for
specifying where GNOME is installed.

> Gnome and KDE are library frameworks that applications might or might
> not link against, raising the question of whether the applications
> should move around depending on how they're linked.  Gnome and KDE
> settle very well into the /usr hierarchy (simply by specifying
> --prefix=/usr).

If we fail to solve the issue about packages optionally linked against
GNOME/KDE I think it would be better to install everything in /usr.

Regards,
  Mikael Hallendal

-- 

Mikael Hallendal
Gentoo Linux Developer, Desktop Team Leader
CodeFactory AB, Stockholm, Sweden