Diff — BLFS

{{infobox

| title = BLFS — Beyond Linux From Scratch

| chapter = Linux Handbook, chapter 24 — the booted system becomes a usable one

| core | LFS boots; BLFS makes it livable — X, sound, browsers, tools

| scope | ~1000+ packages · the ecosystem layer

| the_idea = The base system is a seed; BLFS is the garden

| needs | A booting LFS system — chapter 6's payoff

| next | Troubleshooting & rescue — when it breaks

}}

**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:

```text

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

```text

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

```text

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

| Territory | Depth | Notes |

| --- | --- | --- |

| X11/Xorg | ~50 pkgs | xorgproto → libxcb → libX11 → xorg-server → drivers |

| Wayland | ~30 | wayland → weston → wlroots or compositors |

| GTK/Qt | ~20 each | the app substrate |

| KDE/GNOME | ~60 each | the heaviest desktops |

| Xfce/LXQt | ~20 | the lighter full DEs |

| Firefox | the deepest tree | rust → nss → the browser itself |

| Mesa/GL | ~10 | graphics' foundation |

| PipeWire/ALSA | ~10 | the sound stack |

| Rust/Go/etc | ~5 each | the language layer |

| Postgres/MariaDB | ~5 | databases |

| CUPS + filters | ~10 | printing |

## 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

| Milestone | What it proves |

| --- | --- |

| `startx` gives a desktop | Xorg + drivers + libs all resolved |

| First browser works | The deepest dep tree of all built |

| Sound plays | ALSA + a mixer routed |

| A package *you chose* installed | You navigated the web, not the book's path |

## 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

| Stage | Result |

| --- | --- |

| LFS boots | The seed |

| Utilities + libs | The substrate |

| X/Wayland + desktop | The livable layer |

| Apps + services | The workstation |

| You | The package manager |

## References

- **Hosted mirror**: [/dist/books/](/dist/books/index.html) — the official LFS book mirrored on this site (v10.0–13.1, SysV + systemd editions; CC BY-NC-SA 2.0 / MIT, hosted verbatim with attribution)

- The per-package dep lists — BLFS's real structure

## See also

[[Category:Linux]]

[[Category:LFS]]

[[Category:Handbook]]

[[Category:Linux Handbook]]