Optional prefixes (targeting 7.0)

Bruce Dubbs bruce.dubbs at gmail.com
Wed Dec 3 09:26:34 PST 2008

DJ Lucas wrote:
> Guys and gals,
> Is there any real desire to support the optional installation prefixes 
> of X, QT, Gnome, and KDE in the book after package management enters?  
> Maybe I'm just being lazy, but at this point, I kinda view it as an 
> unnecessary maintenance burden.  Not to mention that the idea of 
> building Gnome and various groups of dependents 2 more times is a bit 
> unattractive, (it's scripted after the first run so it's not like it's a 
> huge pile of work, just takes background time).  That's probably even 
> extreme as I chose to do the most difficult pattern first. The minor 
> changes needed for this variant aren't likely to affect the other 3 
> possible combinations, but I'll do at least the easy one once anyway for 
> validation.
> I imagine the same difficulty occurs with maintaining QT, KDE, and later 
> KDE-4.  I'm not sure about supporting both KDE-3 and KDE-4. 

In my case, I need to have qt3 and qt4 installed simultaneously at least for the 
next year or two.  I support an application that uses qt3 and am porting it to 
qt4 (probably a full year's project).  The headers and libraries of the two 
don't conflict, but the applications, especially qmake, do.

IMO, placing qt/kde/gnome in /opt is an important technique for users to be able 
to experiment with multiple versions with the ability to back up to a previous 
working version when (not if) a build problem is not detected until the system 
is running.

> AFAIK, our counterparts all install in /usr.  
> With package management coming, it 
> shouldn't be any more difficult I suppose, but even more unnecessary IMO 
> now that I actually use what I consider to be a good package management 
> scheme.  The only downside I see to dropping optional prefixes, is our 
> value to upstream in not revealing bugs in configure scripts that might 
> affect someone else.  AFAIK, we've always been good at finding the out 
> of the ordinary bugs and upstreaming patches or docs.

Our audience is quite a bit different from the typical distro.  Our users 
experiment with build flags, specific components installed, and deciding what 
non-mandatory dependencies to install.  I even hesitate to install X in /usr 
because I don't want to drop back to the command line when something goes wrong.

   -- Bruce

More information about the blfs-dev mailing list