Re: Use of the Build-Conflicts field

[Josh Triplett <josh@joshtriplett.org>]

Tollef Fog Heen wrote:
> ]] 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.

Agreed completely. I would consider it *at least* a normal-severity bug
for a package to go from building to not-building after installing
another package, regardless of Build-Conflicts.