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