BLFS use of /opt

dagmar at dagmar at
Sun Oct 6 11:57:17 PDT 2002

Before one must read farther, I'd just like to say I think this is a very
bad idea.  Reasons below...

On Sun, 6 Oct 2002, Mark Hymers wrote:

> As I mentioned in my previous email, I want to draw up a policy on the
> BLFS use of /opt.
> At the moment we use it in several places and ways (--> = symlink)
> /opt/qt --> /opt/qt-version (qt-3.0.5)
> /opt/kde --> /opt/kdeversion (kde303)
> /opt/gnome
> /opt/gnome2
> /opt/mozilla
> /opt/java/j2sdk --> /opt/java/j2sdk-version

I don't see /opt/gnome* listed for any of the Gnome stuff, and my BLFS
tree is current as of 10/02.  I feel this is a good thing.

> Which to my mind is slightly messy.
> I think I'd quite like to standardise on the qt way albeit slightly
> modified.  Now, I know that people can vary from this (and indeed they
> are encouraged to do it their way) but I'd like the book to be
> consistent, so I propose something along these lines:
> so, from above we'd have:
> /opt/qt-3 --> /opt/qt-3.0.5
> /opt/kde-3 --> /opt/kde-3.0.3
> /opt/gnome-1 --> /opt/gnome-1.4
> /opt/gnome-2 --> /opt/gnome-2.0.WHATEVERITISNOW

*ahem* It's 2.0.2.  ...and it wouldn't make any sense to have an
/opt/gnome-2.0.* because Gnome has (and apparently will for some time) be
divisible by minor revisions.  /opt/gnome-2.0 is all that would be
necessary (as 2.1.x should not be mixed with it), and to the extent that
people can _use_ them at the same time it wouldn't really need to go
beyond /opt/gnome1 or /opt/gnome2.

> /opt/mozilla-1 --> /opt/mozilla-1.0.1

Putting Mozilla into /opt breaks from what the Mozilla team expects.  Why
not stick with the perfectly FHS-compliant locations they've chosen by

> /opt/java-1 --> /opt/java-1.4.0
> The instructions would use the proper path such as:
> ./configure --prefix=/opt/qt-3.0.5 etc etc...
> ./configure --prefix=/opt/kde-3.0.3 etc etc...
> But when we suggest adding things to /etc/ and /etc/man.conf
> we'd add:
> /opt/qt-3
> /opt/kde-3
> etc
> I'm quite happy to make these changes as long as I get the OK from each
> of the other editors, I'll also write the page to go in the
> Introduction.
> Does anyone have any objections to this or can forsee any problems it
> may cause?

I can see it causing a lot of complications along the lines of having to
start adding --sysconfdir and --localstatedir to all the Gnome packages to
maintain FHS-compliance, (although that needs to be done already).  Very
likely other packages will need to be changed along the same lines.

The most important thing I can think to ask about this is _why bother with
/opt_?  It's not like you're going to be uprooting that section of the
filesystem and replicating it around an office network or something (and
doing so like THAT would be _incrediby crude_).  The use of it here for
packages and groups of packages where it's not being recommended by the
software authors is just adding unnecessary complexity to the system which
increases the chances of things going awry.  What you're proposing will
bring back the evil demon of $PATH variable maintenance to no real

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

More information about the blfs-dev mailing list