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.
