Hello Ian, On Tue 20 Nov 2018 at 03:24pm GMT, Ian Jackson wrote:
> Sean Whitton writes ("Bug#824495: debian-policy: Source packages "can"
> declare relationships"):
>> I still don't see how we can implement such new rules, though, because
>> of the problem of how to determine whether we're making masses of
>> packages RC-buggy.
>
> I'm going to go back to my table:
Thank you again for your table. I hope that we can improve the
guidelines in Policy that are designed to ensure that packages remain
buildable outside of chroots, in reasonable circumstances. I don't
doubt we have a project consensus that that is worth doing.
> | Package builds MAY be affected, sometimes adversely, by the
> | installation of additional packages beyond the Build-Depends
> | and build-essential, subject to the following rules:
> |
> | Nature of package Effect Permitted
> | on build output
> |
> | Installed by default Any effect MUST NOT
> | with any Build-Depends
>
> (I take your point about deferring to apt, but bear with me for now as
> this wording is clearer for discussion.)
>
> I think almost everyone would already agree that a situation where a
> package build is affected by the presence or otherwise of packages
> Recommended by the Build-Depends, is an RC bug. This should be fixed
> by adding the affecting package(s) to Build-Depends or Build-Conflicts
> as applicable.
Indeed.
> | Part of any reasonble Additional SHOULD NOT
> | default install for features
> | development workstation
> | Build fails SHOULD NOT,
>
> I think this is uncontroversial. NB violations are not RC.
Agreed.
> | MUST Build-Conflict
>
> This is newly an RC bug in my proposal. But it is pretty close to
> existing practice. In practice people, including maintainers, do lots
> of ad-hoc builds other than in clean chroots. That's how one does
> much of one's development. So must such bugs will be detected
> already.
>
> And the RC bug is very easy to fix: add a Build-Conflicts.
This is the kind of case that prompted Santiago to file this bug, so I
am not so confident about how maintainers will feel about bugs requiring
a Build-Conflicts change being filed against their packages.
> | Builds broken MUST NOT
> | packages
>
> I think everyone agrees that this is an RC bug.
>
> | Other packages Additional MAY
> | features
>
> This `MAY' seems a bit controversial but I am not adding a new rule.
> I'm just documenting the existing rule.
Right.
> | Build fails SHOULD NOT,
> | MUST Build-Conflict
>
> This latter part is newly an RC bug in my proposal. I think that this
> is questionable and warrants further discussion. Personally I think
> most people would agree that any missing Build-Conflicts is a serious
> bug, even if all that happens is that the build fails. But I could be
> wrong.
>
> If this is controversial then I suggest:
>
> | Other packages Build fails MAY,
> | SHOULD Build-Conflict
I am much less confident than you that there is such a difference, in
terms of RC-bugginess, between the case of a package that is part of a
standard development workstation install, and the case of other
packages.
> And finally:
>
> | Builds broken MUST NOT
> | packages
>
> This again is surely not controversial. Admittedly it is not clear
> how many packages we are making rc-buggy here, but the fix is easy,
> again: add a Build-Conflicts.
People would already consider packages RC-buggy in this case. So the
Policy change does not /make/ them RC-buggy, so we're fine.
=====
Most of your table is uncontroversial. There are two cases where your
proposal would make packages RC-buggy where we are not completely
confident that they would already be considered RC-buggy:
(1) the package FTBFSs when a package that is part of a reasonable
standard development workstation install is present, and the package
does not declare a Build-Conflicts
(2) the package FTBFSs when a package that is not part of a reasonable
standard development workstation install is present, and the package
does not declare a Build-Conflicts
In both cases, as you've noted, the fix is highly non-disruptive: adding
a Build-Conflicts. Doing that cannot break any maintainer workflows
because the package doesn't build with the item in the Build-Conflicts
installed. Nevertheless, even if maintainers are quite willing to add
the Build-Conflicts entries, they might not consider the RC-severity of
the bugs to be justified.
It is okay for a Policy change to make a small number of packages
RC-buggy that would not already be considered RC-buggy, but given the
nature of (1) and (2), it is impossible for us to determine by ourselves
how many packages this change would affect.
So, it seems that the only way forward is to go ahead and ask the
project what they think about (1) and (2): would they consider those
bugs to be of RC severity? We can see if we can get a consensus on
debian-devel on this question, with text like this:
Hello,
Use of the Build-Conflicts field is currently mostly optional but we
are working on text for Debian Policy that would require its use in
certain cases. There are two cases which we think that everyone
would agree 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.
[statement of (1) and (2)]
If we can't get consensus, and we still think the change is worth
making, we could ask the TC to make a ruling on the RC-bugginess of (1)
and (2) (the Policy Team are trying to make better use of the TC to move
ordinary bugs forward, rather than only going to the TC for the most
controversial issues).
Is my analysis of what's needed for this Policy change right?
Thanks again.
--
Sean Whitton
signature.asc
Description: PGP signature
