Build Notes for LFS 6.6 with Package Users -- Part 1

Quick note: Early in 2011, I completed LFS 6.7 with these same instructions and did not encounter any changes of note.

I. Introduction
I recently completed Linux From Scratch 6.6 (with Slackware 13.1 as the host) using the package users scheme for package management as described in the hint, “More Control and Package Management using Package Users” and using the scripts attached to that hint available here.

The LFS developers do a fantastic job of putting everything together and explaining it well. If one follows the book, it is not difficult to build a running LFS system. Using the package users package management system adds a little bit of complexity, but the hint by Matthias Benkmann is well-written, easy to follow, and more importantly, the attached scripts work very well. The scripts really do simplify package management with package users.

The hint was last updated in 2005 and was most up-to-date with LFS 6.0. Since then, some of the LFS-specific build instructions in part 2 of the hint have become obsolete. What follows are some general and package user-specific build notes, but the bulk of this document is meant to be a replacement for section 7.3 of the hint: “Known Issues with LFS Packages.”

The following notes are for LFS 6.6 because LFS 6.7 was released when I was already halfway through my 6.6 build process. Mr. Mann’s notes are also for LFS 6.6. I am currently in the process of building LFS 6.7 and I will update these notes to reflect any differences I encounter.

II. General Build Notes
Before getting into package user-specific notes, I have a few quick notes on stopping and resuming the LFS build process. Put simply, it can take a while to build an LFS system depending on how much free time one has and how fast one’s computer runs. It took me two months worth of evenings and some time on weekends. I’d spend an hour or two on it after my kids went to bed on most evenings. I hit a few snags and had to backtrack a couple of times. I estimate 80 hours or so worth of work, but that includes the time to compile all of the packages, during which I could do other work.

Of course, this was my first build, and I was documenting the process as I went, so subsequent builds should take much less time.

Nevertheless, I typically do not leave my home computer on all the time, but rather only have it on in the evenings when I’m actually using it. Resuming an LFS build in chapter 5 is pretty easy, just mount your LFS partition(s), type ‘su - lfs’ and you’re in the proper environment to create the temporary tool chain. Resuming the build and entering the chroot environment for chapter 6 and beyond is also relatively easy, but requires entering commands from different sections of chapter 6. I decided to automate that process with the following script:

Be sure to edit the script as noted after chapter 6 to ensure that you’re using the correct patch for chapter 7 and beyond.

Also, notice the comment on mounting devpts. If the gid and mode aren’t specified when mounting the devpts, then the test to make sure the PTYs are working properly (section 6.12 of the LFS book) will fail when logged in as a package user and not for the reason listed in the LFS FAQ! There are a couple of work-arounds to the problem, but providing the proper configuration to mount for devpts is the best solution.

See the note at the end of this document for more information on mounting devpts and the expect -c "spawn ls" test.

III. General Package User Notes
Everything is part 1 of the package users hint is valid and still up-to-date. Part 1 lays out the general concept, procedures, and use of the helper scripts. This is the meat of the hint. Reading it, trying to implement it, reading it again, and referring to it while building really enhances one’s understanding of exactly what happens when one builds and installs software. Part 2 (section 6 and the first two parts of section 7) explains how to install and use the package user scripts.

While the hint is complete and well-written, there are a few points that bear additional emphasis for first time LFS package user users:

A. Recovering from an error.

As the hint says, errors are good. They point out when one package is trying to install files that conflict with another package, give files permissions that aren’t desired (at least without your intervention), or install files to locations that aren’t desired. What the hint does not do is provide detail on how to recover from an error.

Generally speaking, most errors will occur during the installation of a package ('make install'). The hint gives good advice for fixing the common errors, but it usually comes down to making certain additional directories install directories. While it may not be necessary, I made a habit of running the 'uninstall_package' script to get rid of the partially-installed package before I went about fixing the error that prevented a full installation. After addressing the error that prevented installation, 'make install' (or the make_install.sh script described below) can successfully finish the installation.

It is seldom necessary to rerun the configure and make steps of a build on an installation error. The only time that should be needed is when either of those fail with an error.

B. Scripting the build.

The hint strongly suggests using the included ‘build’ script to build packages because it logs the output and errors of all three steps of the build process -- having the error logs is critical to figuring out what went wrong. You can’t just watch for the errors when they scroll past during a build/install.

The provided build script is a model that usually requires editing before running. It does not perform the test suites (usually ‘make check’), so I split it into three scripts (one each for configure, make, and make install) so I could run the test suites manually before installation. I could have (and probably will in the future) run the configure and make steps as one script; if a problem happens in either of those steps, the script will exit on the (now logged) error.

It is a good idea to have a text editor installed in chapter 5 to help with scripting. Nano is a good choice due to its small size and ease of use (Follow the BLFS build instructions).

C. Documenting builds in the .project file and with ‘list_package’

Do fill out the included .project file for each package user. The hint does not recommend creating package users with version numbers (nor does it recommend against it), and after working with package users for a while I understood the advantage of not hard-coding version numbers into package users’ user or group IDs. If I’ve got a package user for bzip, and I want to update bzip, I can use the existing package user to build and install the new version.

How do I tell which version I have installed? Read the .project file. It has space for information on the package name (with version number), download location, and build notes. Most of the information in section IV of this document comes right out of the build notes in the .project files for the packages.

The helper script, ‘list_package,’ is wonderful! Run:

to generate very complete documentation for each package after it is installed. One note, though: the script reads the man page summaries for installed binaries, but that part of the script won’t work until after Man-DB is installed late in the process. I simply reran the list_package script for each installed package after Man-DB was installed.

Continued in part 2 . . .