There are two levels of isolation when building Linux packages
Today I once again had to rebuild an Ubuntu package from source, and once again it didn't go well. This gives me a good opening to talk about the two sorts of build isolation you want when building or re-building packages for your Linux distribution.
The first sort of isolation is isolation of the binary build area from the package source area, which the Debian package format doesn't have; the lack of this isolation can easily cause explosions. Without this isolation, repeatedly building the package is dangerous all by itself; a second build may fail outright or be quietly contaminated by artifacts and changes from the previous build. The Debian package build process at least checks for this and will abort under the right circumstances, saving you from potential problems. By contrast, the RPM build process normally separates these into an area for the package source and a separate area where the package is built, with the build area recreated from scratch every time.
(At the time I set up my RPM configuration, the default RPM setup of package source wasn't ideal because it could comingle components of all packages together. These defaults may have changed since then.)
The second sort of isolation is isolation of the entire build process from your regular user environment and your system's particular set of installed packages (or packages that aren't installed). This is sometimes called a hermetic build environment (or hermetic builds), because the build is completely sealed away from the outside. Without hermetic builds, your environment variables, the state of your $HOME and any dotfiles or other configuration in it, the versions of things on your particular $PATH, and so on may all influence the package you build, for better or worse. A hermetic build environment provides consistency and often makes it easier to re-do or reproduce your (re)build later.
(As a side effect, hermetic builds force packages to relatively accurately describe their build time dependencies and requirements, because otherwise the dependency probably won't be there. I say 'probably' because sometimes a build dependency that you didn't explicitly specify can be helpfully pulled in indirectly by a build dependency that you did require.)
Neither RPM nor Debian packages provide hermetic builds out of the box. For RPMs, mock provides an all-in-one solution that's generally very easy to use. Debian has the sbuild collection of tools (also, sbuild(1)) that, based on my reading, provide the tools you need to do this (I only recently found out about sbuild and haven't tried to use it). If there is a convenient mock-like front end to sbuild and its other tools, I haven't spotted it in Internet searches so far. Ubuntu does have a Setting up sbuild document that makes it look fairly straightforward.
The ideal situation is that hermetic isolation is as fast and convenient to use as the simpler source versus build area isolation, so you can use it all the time. Otherwise, if you have both it's not uncommon to first develop your change by repeatedly building the package the fast way, and then do the final, for-real build with the slower hermetic isolation.
(When working with RPMs, I've been known to not even build and install the binary RPMs; instead I'll have rpmbuild stop after compiling everything, and then I run the compiled binaries out of the build area. This doesn't work for everything, but it can be quite convenient.)
|
|