Sean Whitton writes: > Use of the Build-Conflicts field is currently mostly optional, but Ian > Jackson and I have been working on text for Debian Policy that would > require its use in certain cases. See #824495 for the discussion. > > 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)?
How many packages would be affected by (1) or (2)? I think both are less problematic than the case where the maintainer uploaded a package which has different features than a rebuild on a buildd. That would result in a rebuild (NMUs, next regular upload by someone else or a changed build environment, binNMUs) to change the features available to users. Something we really don't want; note that this could also happen in security or stable updates. (Having Build-Conflicts for the additional features case is probably not implementable with reasonable effort given how autotools and others enable automatic feature-detection by default which isn't really what one wants...) Failing to build in non-standard environments is in contrast a fairly friendly failure mode. So it should not be a serious bug (whether RC or not is something for the release team). > For the purposes of this e-mail, let's assume that we have a good grasp > on what a "reasonable standard development workstation install" means. I doubt we have, but let's ignore that. Ansgar