Re: Use of the Build-Conflicts field

[Tollef Fog Heen <tfheen@err.no>]

]] Sean Whitton 

> There are two cases which we think that everyone would agree that there
> is a bug, but we are not sure that the bug would be considered to be RC.
> We are posting to -devel to see if, in fact, we do have a consensus that
> these bugs would be RC, or not.
> 
> (1) a package FTBFSs when: another package that is part of a "reasonable
>     standard development workstation install" is present, but the first
>     package does not declare a Build-Conflicts against the second
> 
> (2) a package FTBFSs when: a package that is NOT part of a "reasonable
>     standard development workstation install" is present, but the first
>     package does not declare a Build-Conflicts against the second
> 
> Is (1) an RC-severity bug in the package that FTBFSs?  Is (2)?

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»).  I'd be
inclined to say «yes, it should be RC» and either give exceptions or
downgrade that severity if we discover the class of bugs unearthed to be
too large to handle.

> It is worth noting that in both cases, the fix is highly non-disruptive
> to maintainer workflows: you just add the build-conflicts metadata.  But
> how easy it is to fix the bug does not determine whether or not that bug
> is RC.

Build-Conflicts should ideally only be used when properly fixing what
causes the difference in behaviour to be hard to fix.  If it's possible
without expending too much effort, one should rather try to fix what
causes the problem rather than working around it.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are