Re: Use of the Build-Conflicts field
Tollef Fog Heen <tfheen@err.no> writes:
> I think we should (over time) aim towards non-reproducible builds being
> release critical bugs, and I think «builds differently in an unclean
> chroot» is a class of non-reproducibleness we need to tackle («fails to
> build» is really just a subset of «builds differently»).
This feels like a very hard problem if we try to express it through
Build-Conflicts or through careful tuning of upstream build systems. It's
working at cross-purposes with the goal of a lot of upstream build
systems, which try to dynamically discover available optional features and
packages and compile in optional features.
It's so much easier to solve this problem with containers, and the places
where I'm aware of it being solved at scale, it's done with containers, or
with namespacing and related features. One hides from the build system
everything that isn't supposed to be part of the build, and then this
problem becomes much easier to solve.
To be clear, sometimes there are good reasons for Debian to do the hard
thing and try to solve a problem more deeply than others do. But I'm not
sure this is a good example of that, or a good place to invest significant
resources, particularly since it's in the class of problems that would
require work from every individual package maintainer to carefully
configure their build system to not behave differently in the presence of
unexpected packages. Making it seamless and simple to build inside an
isolated namespace feels like a more productive investment and would
benefit every package.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: