Your System, Your Rules: Wiring a Real Package Manager Into a Hand-Built LFS Base

There is a moment every LFS builder knows well. The system boots. The prompt appears. You typed make install dozens of times over a long weekend, and every byte on that disk passed through your hands. Then, three weeks later, OpenSSL ships a security release, and you realize you have no idea which of your forty-odd packages depend on it.

This is the trap we examined in our earlier piece on builders who skipped package management entirely: hand-built systems decay not because they are fragile, but because their maintainers are human. The answer is not to abandon the build-it-yourself ethos. It is to graft a package manager onto the foundation you created — on your terms.

Three Contenders, One Blank Slate

An LFS system is the ideal laboratory for this comparison precisely because it ships with nothing. There is no apt preinstalled, no dnf lurking in the background. Whatever you choose, you choose deliberately. We tested three candidates on identical LFS 12.x builds: pacman from the Arch ecosystem, Nix with its purely functional model, and dpkg, the Debian workhorse.

Footprint: How Much Machine Does It Take?

dpkg is the lightest of the three by a wide margin. It is a single C codebase with modest library requirements — you likely already built everything it needs during your LFS pass. Compiling it from source took under two minutes on our test machine, and the on-disk cost is a few megabytes plus a text database under /var/lib/dpkg.

pacman sits in the middle. Building it requires libarchive, libcurl, and a handful of dependencies, several of which you may not have included in your original build. Expect an hour of dependency wrangling the first time, though pacman itself remains lean at runtime.

Nix is the heavyweight, and it is not close. The daemon, the store, the per-package build sandboxes — Nix wants tens of gigabytes of disk and a build environment that can feel like a second LFS project. Whether that cost is worth it depends entirely on what you want from your system.

Complexity: Installation and Daily Operation

Installing dpkg

The path of least resistance looks like this:

1. Download the dpkg source tarball from the Debian project.
2. Configure with ./configure --prefix=/usr --sysconfdir=/etc.
3. Build and install, then initialize the database with dpkg --configure -a.
4. Author minimal .deb control files for packages you have already compiled, or begin managing new ones from the start.

The learning curve is gentle. The catch is ecosystem: dpkg alone has no remote repository fetching. You are the repository. For LFS builders, this is arguably a feature — but it means writing your own .deb packaging rules for anything beyond the basics.

Installing pacman

Pacman's makepkg system gives you a declarative PKGBUILD format that doubles as documentation of how every package was built. That transparency aligns beautifully with the LFS philosophy: your build recipes live in plain text, version-controlled, reproducible by hand if the tooling ever disappears.

The install sequence is more involved — build libarchive and its dependencies first, then pacman, then create a local repository with repo-add and point your pacman.conf at it. Budget an evening.

Installing Nix

Nix can be installed on nearly any Linux system with its official script or by building from source. On LFS, the script route generally works because Nix brings its own closed world of dependencies. The complication is that Nix deliberately bypasses your carefully compiled system libraries, fetching its own toolchain from binary caches or building in isolation.

Is that a betrayal of the LFS ethos, or the ultimate expression of it? Reasonable builders disagree.

Philosophical Fit: The Tiebreaker

Score the three on paper and it is nearly a draw. What separates them is how each treats ownership of your system.

dpkg assumes you, the administrator, are the authority. It records what you tell it and stays out of the way. This is the closest match to the LFS mindset — but it gives you the least help.

pacman assumes builds should be scripted, repeatable, and honest. PKGBUILDs are essentially the LFS book's build instructions, formalized. If your goal is a maintainable hand-built system rather than a museum piece, pacman offers the best ratio of assistance to intrusion.

Nix assumes nothing about your system and everything about its own store. You gain atomic upgrades, instant rollbacks, and the ability to run conflicting library versions side by side — genuinely remarkable capabilities on a system you built from scratch. You also accept that a substantial portion of your machine now lives outside your /usr and answers to a different set of rules.

The Verdict

For most LFS builders, pacman is the strongest choice. It formalizes what you are already doing manually, its PKGBUILD format preserves the transparency that drew you to LFS in the first place, and its footprint respects the lean system you worked so hard to create.

Choose dpkg if you want the absolute minimum machinery and are comfortable being your own repository. Choose Nix if your priority is rollback safety and experimentation on top of a foundation you understand at the byte level — and you have the disk space to prove it.

Whichever route you take, the principle stands: a hand-built system without package tracking is a system with an expiration date. Pick your tool, wrap it around your work, and keep building.