On Friday, February 15, 2019 08:59:41 PM Sean Whitton wrote: > Hello, > > 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)? > > 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. > > 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'll bite. I think "reasonable standard development workstation install" is the wrong class of standard (whether I have a grasp on it or not). If it's not going to cause an FTBFS on a buildd, I think it's not RC. That would limit it to packages that are build-depends (direct or indirect) of other packages, i.e. no leaf packages. So my answer to both your questions is no. Scott K
Attachment:
signature.asc
Description: This is a digitally signed message part.