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.)
Source link