BLFS

LFS ends with a booting system; BLFS makes it a living one. Beyond Linux From Scratch is the companion book covering what the base deliberately skips: X11/Wayland, sound, networking services, desktop environments, browsers, programming languages, printing, and the thousand packages that turn a minimal system into a workstation. This chapter maps the territory — and the dependency web that makes BLFS genuinely harder than LFS.

The web, not the chain

LFS is a sequence — every package ordered, one path. BLFS is a web — hundreds of packages, each needing others, the order implied by dependency, not chapter. The discipline shifts: you're choosing paths through a dependency graph — install libX before Xorg, Xorg before the desktop, the desktop before its apps. BLFS's index is alphabetical — the book assumes you navigate by need, not sequence.

The major territories

• X11 / Wayland — the display servers — Xorg's server + xorg-drivers + the Mesa GL stack; Wayland + compositors the modern path
• Sound — ALSA (kernel-level mixer) + PipeWire/PulseAudio (the routing layer)
• Desktop environments — Xfce, LXQt, KDE Plasma, GNOME — each a large subtree of its own deps
• Programming languages — Python (built in LFS, extended here), Java, Go, Rust, Ruby — the dev layer
• Servers — apache/nginx, databases (sqlite/postgres/mariadb), mail, DNS
• Libraries — Qt, GTK, the crypto stacks, imaging libs — the substrate everything hangs on
• Applications — browsers, office, media
• Printing — CUPS
• The toolchain adjacents — gdbm, the doc systems (docbook, gtk-doc), llvm/clang as an alternative compiler

The dependency grammar — reading a BLFS page

Each BLFS page declares:

Required:    libx, liby            — won't build without
Recommended: libz                  — most builds want it
Optional:    libopt1, libopt2      — features you choose

The skill: build Required first, Recommended for a full system, Optional deliberately. Optional deps silently activate if present — a system where libfoo happened to be installed builds differently than one without — the reproducibility hazard of the web.

The actual dependency trees — what installing X really pulls

Xorg-server:
  xorgproto → libXau → libXdmcp → xcb-proto → libxcb
  → libX11 → libxtrans → libpciaccess → libdrm → mesa
  → libepoxy → libXfont2 → pixman → nettle → xorg-server

Firefox (the deepest tree in the book):
  rust → cbindgen → nss → nspr → icu → nodejs → python-modules
  → gtk+3 → pango → cairo → freetype → fontconfig → glib → dbus
  → alsa-lib → libevent → libvpx → ffmpeg-deps → firefox
  — ~40 prerequisites; rust alone takes ~10 SBU

GNOME/KDE — each ~60 packages deep; a desktop is a *tree* not a package.

Required: is the floor; Recommended: is the working set; Optional: is the feature surface. Firefox's ~40-deep tree is why "just build a browser" is a week.

The orderings — the canonical path

X11 branch:        util-macros → xorgproto → libXau → xcb-proto → libxcb → libX11
                   → libXext → ... → xorg-server → mesa → xorg-drivers → fontconfig
Desktop branch:    X + GTK3/Qt → DE's own libraries → the DE
Sound branch:      alsa-lib → alsa-utils → pipewire → wireplumber
Browser branch:    rust → nss → ... → firefox (the deepest tree)
Printing:          cups-filters → ghostscript → cups

The strategy — what to build first

The sane order:

1. The utilities — which, pciutils/usbutils, sudo, wget — the tools missing from LFS's minimal set
2. The library substrate — the crypto libs (gnutls, p11-kit), XML/JSON, imaging — everything else hangs on them
3. X or Wayland — the display stack is the largest dependency tree
4. A desktop — Xfce first (the lightest full one)
5. The applications you need

The dependency discipline: BLFS's per-package pages list "Required / Recommended / Optional" deps — build required first, recommended for full features, optional deliberately. The graph reading is the skill; the book's the map.

The major trees — what each territory costs

The tools that scale BLFS

A 1000-package web can't be tracked by memory alone:

• make discipline — the same liturgy, but deps order it
• DESTDIR staging — the packager's install: make DESTDIR=/stage/x install → inspect what lands before it hits /
• Log every build — make install | tee /var/log/pkg/name.log — the primitive package manager: the log is the manifest; uninstall = rm the logged paths
• A scratch dependency list — track what each package pulled; the rdepends graph lives in your notes, not a database — LFS means you're the package manager

The honest trade — you are now the package manager

BLFS's real lesson: a real distro's package manager isn't convenience — it's knowledge. Without one, upgrades mean rebuilding; dep changes mean re-tracking; "what installed this file" means your logs. Some LFS builders adopt a minimal manager (pacman can be grafted on, or installpkg-style txz tools); most keep the journal + logs approach — full visibility, full labor. Either is legitimate; the choice teaches what distro infrastructure actually costs.

Eyes-free BLFS

The console-side BLFS packages — espeak-ng, brltty, emacspeak — bring the accessibility layer into a built system; a speaking LFS workstation is achievable entirely from source. The graphical side (Orca + GNOME/Xfce) is the heaviest BLFS territory — and fully buildable.

The milestones worth marking

Exercises

1. Pick one target app; trace its dep tree three levels deep — the web, mapped.
2. Build one recommended-but-not-required dep; note what it unlocked.
3. DESTDIR-stage a package; find what it would install before installing.
4. Write your own uninstall recipe from install logs.
5. List what your LFS system can't do yet — the BLFS gap, concretely.

Timeline

References

• linuxfromscratch.org — the BLFS book (SysV + systemd editions)
• The per-package dep lists — BLFS's real structure

See also

• LFS Kernel and Boot · Building from source · Linux