Web lists-archives.com

Re: Use of the Build-Conflicts field




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.