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: [phone]               ||  matter of life or death...
email: jerry@×××××××.org          ||  ...It's much more important
                                  ||  than that!