Re: Use of the Build-Conflicts field
On Sat, 16 Feb 2019 10:54:25 -0800, Russ Allbery wrote:
> 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.
>
This will of course depend on how the upstream build system works, but I
think it is best practice for debian packages to explicitly enable and
disable features that are in use, and fail the build if they cannot be
built. Having packages that may have different features when built
locally or when some transitive dependency changes, can introduce subtle
and hard to diagnose bugs.
--
Saludos,
Felipe Sateler
Reply to: