On 2/16/19 7:08 AM, Scott Kitterman wrote: > 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. > +1
I'd say (1) and (2) range somewhere from minor to normal severity. Cheers, Julien
