Beyond Linux From Scratch 1.0 Released

An anonymous reader writes "DistroWatch reports about the 1.0 release of Beyond Linux From Scratch (BLFS), a subproject of Linux From Scratch: 'The BLFS Development team is proud to announce the release of BLFS 1.0. With this release, you can take your LFS 4.1 base beyond a development system. It can be a desktop, a firewall, a multimedia player/editor, an Apache web server or all of the above. You install only what you need. Your Distro. Your Rules. Enjoy.'" Choose the closest mirror...

Comments

Avoid package hell / parallel src installs (long!)

[Deagol]

I understand the RPM dependency hell very well. I recently did a full, clean RedHat 9 install. I then downloaded all the source RPMs from freshrpms, mostly for the multimedia capabilities. A quick 1-line bash script went through the entire batch and attempted to build them. Of course, some needed to be built and installed before others, so about 30% failed. I installed what did build, then repeated this process several more times. The mplayer package was the worst by far.

Anyway, I don't understand how anyone has trouble installing packages from source. You just need to partition them appropriately. I wish distributions used a similar method so they could keep parallel versions of programs and libraries installed.

Take openssh, for example:

My typical build of openssh requires: zlib, openssl, and tcp_wrappers.

I use a structure I call /mfs ("My File System"). I could use /usr/local for the same thing, but a customized directory will prevent collisions in /usr/local (the usual default prefix for configure scripts).

Under /mfs I have directories "dist" (the tarballs), "src" (where I untar and build each package), and "pkg" where I install packages.

So I start with zlib: "./configure --prefix=/mfs/pkg/zlib/1.1.4 ; make ; make test ; make install".

I repeat with tcp_wrappers, openssl, and finally openssh. So now I have the most current versions:

• /mfs/pkg/zlib/1.1.4
• /mfs/pkg/tcp_wrappers/7.6
• /mfs/pkg/openssl/0.9.7a
• /mfs/pkg/openssh/3.6.1p1

It should go without saying that I configure openssh to use the zlib, openssl, and wrappers libraries under /mfs, rather than the default system libraries. To the anal purists out there, I don't do this with all libraries (such as glibc), as it would drive me insane -- but it could theoretically be done.

Here's where it gets elegant (or convoluted, depending on your tolerance for complexity). Under each package's directory, I use a symlink from the version I wish to use on a regular basis to "std".

So, under /mfs/pkg/openssh, I may have directories 3.6.1p1, 3.0.1p1, and 2.9.9p1. Let's say that I want to use the latest sshd, so I run "cd /mfs/pkg/openssh ; ln -s 3.6.1p1 std". I then cd back up to /mfs. I then issue "lndir pkg/openssh/std". Actually, I have a script in /mfs that automatically removes all existing links under /mfs (avoiding the "pkg" dir, for obvious reasons) then re-linking every package with a "std" link. (Note I don't use a "std" link -- and thus don't lndir -- for libraries without runable binaries). If you don't know how lndir works, check it out (it's from the XFree86 distribution, though that might not be where it originated.).

After running lndir (or my script), I now have /mfs/{bin,etc,var,lib,sbin}. I point my sshd startup script to always use /mfs/sbin/sshd, which is actually a link to /mfs/pkg/openssh/std/sbin/sshd. Since std is a symlink to the version I wish to use, I can change to a newer or older version by simply stopping sshd, changing the "std" link to point to another version, and restarting sshd.

The beauty is that still have other versions available to me. Say the scp provided in 3.6.1p1 has an irritating bug (not the case, but just imagine). If my normal PATH has /mfs/bin, I'll get scp v3.6.1p1, but I can fall back to running /mfs/pkg/openssh/3.0.1p1/bin/scp.

This technique is especially valuable in multi-user systems, where libraries and applications of different versions (think compilers, for example) have dedicated users who aren't ready to upgrade.

Sorry for the really long post, but this idea works extremely well, IMHO, and I'm surprised that no distros use a similar technique for maintaining parallel versions. If RPM used this technique, you'd never run into the case where a new app needs a newer library version, but upgrading that library isn't possible since other major applications require that specific version (such as KDE needing a specific version of libpng and libcrypt).