[Death to] /opt/gnome

dagmar at speakeasy.net dagmar at speakeasy.net
Thu Oct 10 12:43:08 PDT 2002

(Before anyone gets the idea that I'm an obsessive compulsive about
mailing lists, I'll mention that I've been punting around with these very
issues since the 1.2.x kernels, the last three years or so specifically
with an eye towards relasing my own CDs eventually, so I've just had a
_lot_ of time to think about this.)

On Thu, 10 Oct 2002, Larry Lawrence wrote:

> Ok , I woke up this morning with an open mind (well, not open, but there's a
> crack).
> To generalize where we are in this discussion, each of you has made an
> educated decision as to where gnome goes. Now do the impossible and
> uneducate yourself.
> This is your first time to compile Gnome, you don't know what to expect, You
> have 50 packages to install and one error may break the whole process.

This is why following instructions is a very important skill, much to the
dismay of the unwashed masses coming over from Win32.  As hard-nosed as I
may appear to be about not playing fast and loose when building Gnome, the
Gnome devs I've dealt with on GimpNet are even _worse_ about it.
However, in most cases, when I take a strong stance on a particular issue
surrounding Gnome2, it's because I have _personally_ been burned (because
some setting didn't behave as I expected and broke a buncha stuff) and had
to rebuild the entire thing (and in some cases, manually rummage through
/usr/share looking for loose pieces) starting from the top.

> Those of us who have done this know that if (I should say when) they make a
> mistake, we may have to tell them to start over.

Yep.  I hate to have to say that to folks, but thankfully it's not
necessarily nearly as often as it might have been with Gnome 1.4.x.  Three
different times I've had to isolate my builds, and every time I've
rebuilt things into /usr they've all done the right thing.

> How do we get a clean slate with a prefix other than /opt?  (Remember, in
> the context of BLFS, we don't currently include a package management
> system, Mark has discussed it and it will probably happen, but under the
> current situation, it is not available).

You can't really expect a clean slate with _any_ of these packages if the
user has been building things in bizarre and unusual ways before you got
to 'em.  Thankfully it's pretty easy to cajole the build scripts as they
stand now (in the past I bitched at plenty of people about it when I'd
find one that was broken) into uninstalling packages with a simple `make
prefix=/usr/stupid uninstall`.

> Are we out of compliance with FHS by using /opt? (I'm firmly in belief that
> we are in compliance, so please be specific on your concerns)

Not specificaly related to compliance by _using_ /opt, but evidence to the
fact the current Gnome sections at least are _not_ FHS compliant I direct
everyone's attention to point in FHS 2.2.  (There are other, more
direct reasons why the current documentation results in a non
FHS-compliant system that I will leave as an exercise to the reader.)

3.7.4 /etc/opt : Configuration files for /opt Purpose

Host-specific configuration files for add-on application software packages
must be installed within the directory /etc/opt/<package>, where <package>
is the name of the subtree in /opt where the static data from that package
is stored.

This is simply not being adhered to in the least.

Here's our problem at hand as I see it...

The FHS document is a good thing, but _only_ within the scope of it's
stated purpose.

It says _almost nothing_ about building an elegantly and intelligently
architectured system.  You can build your system so that almost everything
that would normally go into /usr is installed into /opt, up to and
including the compiler toolchain, and have a PATH variable that spans five
full lines of 80 characters, and it will _still_ be 100% FHS-compliant.
It will be spending a MUCH larger share of it's time searching paths, and
suddenly the whereis and which utilities will be packing their things and
eyeballing the /bin directory while picking out wallpaper and picking out
paint swatches, but it will work.

The only place it gets close to mentioning some discriminator by which we
can make something of a learned decision about whether to /opt or not to
/opt is in the rationale commentary at the tail end of section 3.12.2,
which is actually the _requirements_ section for /opt and not the purpose
section--and I quote...

  "Generally, all data required to support a package on a system must be
   present within /opt/<package>, including files intended to be copied
   into /etc/opt/<package> and /var/opt/<package> as well as reserved
   directories in /opt."

I think we can safely make the assumption that dependencies which would be
fulfilled by /lib, /bin, and /sbin can be excepted from this statement
(Oracle notwithstanding *chuckle*).  Having that phrased as "generally" is
annoyingly milquetoast but I think it supports the argument before about
/opt only being for software that isn't expecting to be spending much time
socializing with other binaries on the system.

Unless the software developers of a particular package are clearly
instructing people and distributions to put their software into /opt, I
think they should be aiming for {/usr,/var,/etc} with their builds, for
much the same reason that the book is telling people /usr and not

   *   *   *

Now to other matters of brokenness of varying degrees...  I've had a
little time to look over what's in the BLFS book now and I can really only
just shake my head at some of it.

 - There is no point in creating both an /opt/gnome and an /opt/gnome2
  hierarchy in an effort to keep the two trees separate--if you're only
  going to build enough of the Gnome 1.4.x tree to make sure that Gnome
  1.4.x apps can run.  None of those packages have filespace collisions of
  any significance.  If you're going to build _all_ of both of them, you
  MUST do that very thing, as well as twiddle your PATH variable when you
  switch between them, because they _will_ break each other in dramatic
  ways.  However, now that the system-tray-applet for the Gnome2 panel has
  been put into a release tarball (albeit with a very low and scaryish
  number, but Robot101 has assured me it's solid enough) and Gaim 0.60cvs
  appears to work fine with it, the last reasons for doing a complete
  double build of Gnome are fading fast--and they were already
  substantially overmatched by my reckoning.

 - I'd really like someone to point out where in the Developer's guides
  for either Gnome 1.4.x or Gnome 2.0.x the variable GNOME_LIBCONFIG is
  cited.  I have never seen this sucker mentioned anywhere before.  The
  fact that it's set to /usr/lib makes me suspect it's yet another case
  of specifying defaults unnecessarily (which is bad--I'll 'splain later).

 - libaudiofile and esound should be removed from XII-41 as they are
  dependencies of Gnome.  Considering that very little of section 41 appears
  be significantly dependent on anything else, I think it would probably
  more useful if most of section 41 were moved into chapter III with the other
  libraries.  Just say so if the BLFS book isn't trying to follow the
  top-to-bottom approach that the LFS book uses--otherwise I'm probably
  going to have more things to say along these lines later on about other

 - The use of varying configuration options throughout the entire Gnome
  section is a mess.  Gnome-libs in particular makes my hair stand on end.

 - Verily, I doth submit that the use of yon 'whilst' is summat foolish.  ;)

I can only hope that when I go back online tonight I'll be able to pull
the XML version of BLFS from the server and crank out a _massive_ diff
over the weekend to make the Gnome2 builds entirely FHS-compliant (which
is a hell of a lot easier without /opt in the way).  I thought that the
Xfree86 build page was a mess, but I see that it's just a minor doddle
compared to that section.  Whoever wrote it shouldn't feel too bad,
because just being able to get the list of all those damn packages lined
up and cull out the ones not necessary to running Gnome 2.0.x is a massive
task all by itself.  (See my next email about the XFree86 builds)

Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe blfs-dev' in the subject header of the message

More information about the blfs-dev mailing list