Bug#824495: debian-policy: Source packages "can" declare relationships

[Ian Jackson <ijackson@chiark.greenend.org.uk>]

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:

|   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.

|     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.

|                                                  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.

|                                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.

|                                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

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.

Ian.

-- 
Ian Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.