Optional prefixes (targeting 7.0)
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
> 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
> 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.
More information about the blfs-dev