Building OS Packages the Right Way

It’s good to use and build operating system packages. I used to run an HPC system that way, and share the packaging I’d done.I should write about the experience.

However, I see people building them the wrong way — without using the appropriate tools — in particular, so that they’re likely to get dependencies wrong.

You want the build to be isolated, both from the host file system and probably the network. That means you don’t accidentally depend on things installed on the host, or on sucking in random things from the net.Yes, far too many things depend on that, and especially without pinning a version verified by a hash. You may have heard of ‘supply chain’ vulnerabilities.

It also means there’s no risk of trashing something you have write access to by making a mistake in the package description; I’ve fallen for that in RHEL 5. GNU Guix and, I guess Nix, which I know less about, is a good exemplar. (I’m only considering GNU/Linux-type distributions.)

Aside from Guix’ system, documented in its manual, mainstream GNU/Linux distributions have their own systems (and packaging guidelines, which it’s worth trying to follow in any add-on packages you make). These systems, at least ones I’m familiar with, depend on a degree of privilege to operate, though in Guix/Nix’ case, it’s a privileged daemon.

Fedora and RHEL derivatives use mock,There used ot be a mock package in Debian for cross-building rpms, but it’s not in Debian 11.

with which I’m most familiar, to build a source rpm as an alternative to a simple, unclean rpmbuild --rebuild. So, if you’re working standalone, you’d run rpmbuild -bs on your .spec file under ~/rpmbuild to get the srpm, and build the rpm by passing it to mock. Mock ships with a selection of distribution chroots you can target, so you don’t have to build on the system you’re targeting, or even the same architecture with QEMU magic. You might like to use Fedora copr to make a personal repository of package builds available, like mine.

I don’t know what the (open)SUSE equivalent of Mock is, but the mock-core-configs package has chroot configurations for openSUSE which you could use. OpenSUSE’s build system, available for personal package distributions analogous to copr, is OBS. It predates copr, and is actually more powerful:See the copr FAQ.

it can build Debian-style dpkg packages as well as rpms (and AppImages). I’ve found some problems with OBS failing to build packages which work in mock and the Fedora infrastructure, however.

Debian has variations on tools for isolated building, analogous to mock, as an alternative to simple debuild, analogous to rpmbuild.I guess the same possibilities are all in Ubuntu, but I don’t know.

The package maintainers’ guide considers sbuild, for consistency with the official build architecture. There’s also at least pbuilder, via pdebuild(1), with several add-ons. Debian doesn’t have an equivalent of copr/OBS, but Ubuntu has the PPA system, and you can use OBS for Debian packages, as noted.

Other distros, like Arch and Alpine, I don’t know about, but doubtless you can research packaging and isolated builds if you want to target them.

If packages from scratch, consider expending a bit of making the builds reproducible. That’s expected in Guix and Nix and applied to a lot of packages in Debian, but Fedora doesn’t have the same emphasis.

When you’ve built a package, do make sure that it’s installable in a clean root. If you have dependent packages to build — one hopes not a circular dependency, but it’s been known — it’s convenient with mock’s --chain option. It’s less convenient with pdebuild — see the documentation about using previously-built packages.

Incidentally, I recommend maintainers of pieces of software for Unix-y systems to do at least rpm and dpkg packaging for it, following the system packaging guidelines, to ensure it’s sane to build and install. In that connexion, it’s worth checking out a talkWith unfortunate disclaimers presumably directed at a non-European audience.
[“I went to the US and I forgot to pack my irony but, you know, I just didn’t need it.” — Mark Radcliffe, Radio 1 as was]

that mirrors my experience. As far as I remember, I’ve come across all the cases considered, either with the software mentioned, or the same sort of thing with other systems. I’m not a fan of Easybuild, whence that experience comes, though, because it’s more a build system than a real package system (like Spack in that space if you must avoid OS packaging).