[blfs-dev] [blfs-book] r11616 - trunk/BOOK/x/lib

Armin K. krejzi at email.com
Mon Aug 12 02:27:42 PDT 2013

On 08/12/2013 03:11 AM, Bruce Dubbs wrote:
> Armin K. wrote:
>> Installing a library over the existing library which is currently being
>> used is user's mistake, no ours. We shouldn't bother to support such
>> setup. We don't offer package management, we shouldn't care for updates.
>> That should be up to user.
> That's an interesting position to take.  What about installing Xorg in 
> /usr?  What happens if there is an update?  How convenient is
> If it's installed in /opt, then the user can freely install, switch with 
> a simple symlimk change and switch back if there is a problem.

The myth that every component should be rebuild at "few packages
upgrade" is plain wrong and incorrect. X11 api hasn't changed in 30
years. It has just been extended, and update is only necesary for the
package that can use the extended part.

For example, when you update one, if not all, of Xorg Protocol Headers,
there is no reason to rebuild everything. Mostly libraries and XServer
use such headers, and it might be only necesary to rebuild xserver and
libraries that use them only if you want to use new definitions (in
which case build without them would fail in the libs or xserver stage).

As for the libraries (applies to all libs in xorg chapter), the same
applies as for the protocol headers. The only difference might be that
someone used a definition from a git that wasn't available in any stable
release before and when the latest release includes the new definition,
a definition from the package might conflict with the one from xorg lib
package (see SDL example). Also, something might get deprecated in the
newer release, so packages building with -Werror might fail to build if
it uses the function which was deprecated in last release. Packages at
runtime shouldn't feel any difference because ABI is preserved and
should never ever break (see the first paragraph). I am not sure how
safe is to overwrite libraries when installing them if they are being used.

I won't mention apps, fonts, xbimaps, cursor-themes ... Do you expect
something of these would break something? I don't think a font or an app
used to set resolution should break something. As for the apps, only new
functionality might be added, the old one is preserved (again, see
example 1).

Mesa is also safe to update since OpenGL ABI/API hasn't changed in 15
years iirc and you could only benefit from new
extensions/optimisations/hardware support and such. Things can break,
nothing is bug free (by break I mean something is wrong with the
rendering, etc) - mostly runtime errors. Build time errors rarely happen
since API/ABI never changes, it just gets extended.

> The same approach can be made for Qt and KDE.  I've been using in for 
> many years through many upgrades.  I still have the following in /opt on 
> one system:

KDE isn't really "isolated" in the current instructions. It still
installs dbus files into /usr hierarchy and that could possibly mean the
new files break older version, and if new version is broken also you
can't just go back to the old version. I doubt this should happen, but I
don't thing it couldn't. I do preserve all the installed files in a
DESTDIR or equivalents, and only copy them to the filesystem when I set
everything up and remove older version. But then, everyone has its own
package management. This isn't, and shouldn't be up to {,B}LFS to care
what would happen if an update goes wrong. We add/upgrade the packages
with the "guarantee" that package (or set of packages) otherwise works
if built against the current package set.

> ant -> ant-1.8.3
> ant-1.7.0
> ant-1.8.3

Java packages are mess by itself and they need to be in one dir. For
example I installed fop and ant into /usr/share/java/{fop,ant} and added
wrappers into /usr/bin to invoke them and set necesary env vars.

> kde4 -> kde-4.8.3
> kde-3.5.2
> kde-4.8.3
> qt -> qt-4.8.2
> qt-3.3.5
> qt-3.3.8
> qt-3.3.8-nomysql
> qt-4.3.4
> qt-4.5.0
> qt-4.5.2
> qt-4.7.0
> qt-4.8.2
> qt4 -> qt-4.8.2
> fop -> fop-0.93
> fop-0.20.5
> fop-0.93
> gnome -> gnome-2.18.3
> gnome-2.18.3
> Another system does the same thing for OpenJDK and Xorg.
> I do not have to destroy an installation to try out a new one.  That's 
> my distro and my rules.  I want to let others try it out and see if it 
> works for them.

I think Java should be isolated by itself. For example, I only use
binary jre and it is bundled into one dir. I just install the dir to
/usr/lib/java and create symlinks to the binaries and java plugins. I am
not sure about OpenJDK, I never tried it.

> In your case, you don't like it and you use your rules for your distro. 
>   That's perfectly fine.  I'm not trying to convince you.  I do want 
> users to see that there is more than one way to do things.  I'm quite 
> willing to help users who user either method or one of their own devising.
>    -- Bruce

Yes,  but I can't guarantee that everything else will work with the
"more than one way", and we'll see failures. That's the only reason why
I see it as bad. Lets hope Xorg will get replaced by wayland soon ...
(read next 3-5 years).

More information about the blfs-dev mailing list