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

[Ian Jackson]

Sean Whitton writes ("Bug#824495: debian-policy: Source packages "can" declare 
relationships"):
> 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?

I think this is overkill process-wise but it is a reasonable way
forward.

If we don't get consensus on the stronger rule it would be better to
seek consensus on a weaker rule or a weaker normative status, than to
invoke the TC for this issue, IMO.  IOW I don't think this is
important enough to escalate.

HTH.

Ian.

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

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

[Sean Whitton]

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  EffectPermitted
> |on build output
> |
> | Installed by default   Any effectMUST 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  AdditionalSHOULD 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 AdditionalMAY
> | 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 t

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

[Ian Jackson]

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  EffectPermitted
|on build output
| 
| Installed by default   Any effectMUST 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  AdditionalSHOULD 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 AdditionalMAY
| 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 JacksonThese 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.

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

[Sean Whitton]

[This bug was closed by the upload of debian-policy I just did, since I
believe that I fixed the problem in the original report.

I do not mean to suggest by this that I think discussion should end.  We
can clone and reopen when we have a more concrete change proposal]

Hello,

On Mon 12 Nov 2018 at 01:39PM GMT, Ian Jackson wrote:

> Sean Whitton writes ("Bug#824495: debian-policy: Source packages "can" 
> declare relationships"):
>> Do we really want (ii)?  It seems like a recipe for all sorts of
>> confusion.  Do any packages currently work like that?
>>
>> In order to implement something like this, we'd need to rebuild the
>> archive on a "development workstation" to confirm we weren't making a
>> lot of packages RC-buggy.  (It is not clear to me that such packages
>> would be considered by most Debian participants to be RC-buggy in
>> advance of a Policy change like this one being proposed.)
>
> I am confused.  In your first paragraph you seem to be suggesting
> deleting my (ii).  The result of that wold be to declare rc-buggy any
> package which currently falls into my (ii).
>
> In your second paragraph you seem to be shying away from declaring
> anything rc-buggy.  But you refer to a "development workstation" and
> the text from my proposal which mentions that is this:
>
>> >  Any additional package which could reasonably form part of a
>> >  default install for a development workstation SHOULD NOT have any
>> >  significant effect.
>
> That's just a SHOULD NOT.  So what I am declaring buggy is the
> behaviours that you and Simon seem to be objecting to - only I
> restrict the bugginess to "development" packages.
>
> The reason for this rule is practical: the point is that you SHOULD be
> able to rebuild a package "well enough" for use, without needing a
> chroot etc.
>
>
> Can I suggest that the best way to think about this may be the tabuler
> form of my proposal ?  Lookng at individual rows there (including
> their definitions and my proposed consequences) may be easier than
> trying to figure out what people mean when they say "are we sure we
> want (ii)" when (ii) is an exception to a conditional prohibition.

Sorry about this.  I was thinking of the practice permitted by (ii) as
something implemented by the Debian package maintainer, rather than
something implemented by upstream in their build system.  That's why I
was against any text that seemed to permit a Debian package maintainer
implementing something like that.

I agree that if we implement new rules about when packages beyond those
listed in build-depends and build-conflicts may affect a build, we need
to include (ii) as an exception to such a rule, because plenty of
upstream build systems work this way.

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.

-- 
Sean Whitton


signature.asc
Description: PGP signature

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

[Sean Whitton]

Hello,

On Mon 12 Nov 2018 at 01:23PM GMT, Ian Jackson wrote:

> Sean Whitton writes ("Bug#824495: debian-policy: Source packages "can" 
> declare relationships"):
>> On Sun 11 Nov 2018 at 11:31AM GMT, Simon McVittie wrote:
>> > I think the best practice is for maintainers to notice new features being
>> > added, make a deliberate decision on what to enable (in an architecture-
>> > or kernel-specific way if appropriate), and use the equivalent of
>> > --disable-apparmor for any feature we don't (yet?) want to enable.
>>
>> Right.  ISTM that it would be a bug if this was not done, which is why
>> it seems unwise to include Ian's (ii) in Policy.
>
> I think it could easily be more convenient for derivatives to take the
> alternative route.  If I were the Debian maintainer and also the
> maintainer in a derivative, I might prefer to keep the source package
> delta as small as possible.
>
> Depending on the circumstances the source package delta for that
> package might vanish entirely and the divergence dealt with entirely
> through changes to the build dependencies, or build environment (eg
> apt pinning), which mean that the Build-Depends has a different
> result.

Hmm.  I could be convinced with examples, but the cost to users of
Debian for not following the best practice described by Simon seems too
high.

> Currently everyone agrees with me that the behaviour permitted by my
> (ii) is probably common.  So we cannot forbid it with a MUST.

Indeed.

-- 
Sean Whitton


signature.asc
Description: PGP signature

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

[Ian Jackson]

Sean Whitton writes ("Bug#824495: debian-policy: Source packages "can" declare 
relationships"):
> On Thu 08 Nov 2018 at 02:51PM GMT, Ian Jackson wrote:
> > Or to put it another way:
> >
> >  Package builds MAY be influenced by the presence in the build
> >  environment of additional packages, beyond the Build-Depends and
> >  build-essential.  However:
> >
> >  Additional packages MUST NOT have any effect other than either:
> >
> >(i) a failure of the build, in which case the additional packages
> >MUST be declared in Build-Conflicts); or
> >
> >(ii) output packages with additional features or functionality.
> >Such additional features MAY imply additional functional runtime
> >dependencies, which then SHOULD be represented in the output
> >packages' metadata.  In this case the additional packages
> >SHOULD NOT be declared in Build-Conflicts.
> >
> >  Additionally, in any case: additional packages which are installed by
> >  default by apt when the build dependencies are installed MUST NOT
> >  have any significant effect.
> 
> Do we really want (ii)?  It seems like a recipe for all sorts of
> confusion.  Do any packages currently work like that?
> 
> In order to implement something like this, we'd need to rebuild the
> archive on a "development workstation" to confirm we weren't making a
> lot of packages RC-buggy.  (It is not clear to me that such packages
> would be considered by most Debian participants to be RC-buggy in
> advance of a Policy change like this one being proposed.)

I am confused.  In your first paragraph you seem to be suggesting
deleting my (ii).  The result of that wold be to declare rc-buggy any
package which currently falls into my (ii).

In your second paragraph you seem to be shying away from declaring
anything rc-buggy.  But you refer to a "development workstation" and
the text from my proposal which mentions that is this:

> >  Any additional package which could reasonably form part of a
> >  default install for a development workstation SHOULD NOT have any
> >  significant effect.

That's just a SHOULD NOT.  So what I am declaring buggy is the
behaviours that you and Simon seem to be objecting to - only I
restrict the bugginess to "development" packages.

The reason for this rule is practical: the point is that you SHOULD be
able to rebuild a package "well enough" for use, without needing a
chroot etc.


Can I suggest that the best way to think about this may be the tabuler
form of my proposal ?  Lookng at individual rows there (including
their definitions and my proposed consequences) may be easier than
trying to figure out what people mean when they say "are we sure we
want (ii)" when (ii) is an exception to a conditional prohibition.


Ian.

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

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

[Ian Jackson]

Sean Whitton writes ("Bug#824495: debian-policy: Source packages "can" declare 
relationships"):
> On Sun 11 Nov 2018 at 11:31AM GMT, Simon McVittie wrote:
> > I think the best practice is for maintainers to notice new features being
> > added, make a deliberate decision on what to enable (in an architecture-
> > or kernel-specific way if appropriate), and use the equivalent of
> > --disable-apparmor for any feature we don't (yet?) want to enable.
> 
> Right.  ISTM that it would be a bug if this was not done, which is why
> it seems unwise to include Ian's (ii) in Policy.

I think it could easily be more convenient for derivatives to take the
alternative route.  If I were the Debian maintainer and also the
maintainer in a derivative, I might prefer to keep the source package
delta as small as possible.

Depending on the circumstances the source package delta for that
package might vanish entirely and the divergence dealt with entirely
through changes to the build dependencies, or build environment (eg
apt pinning), which mean that the Build-Depends has a different
result.

Currently everyone agrees with me that the behaviour permitted by my
(ii) is probably common.  So we cannot forbid it with a MUST.

Ian.

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

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

[Sean Whitton]

Hello,

On Sun 11 Nov 2018 at 11:31AM GMT, Simon McVittie wrote:

> I think the best practice is for maintainers to notice new features being
> added, make a deliberate decision on what to enable (in an architecture-
> or kernel-specific way if appropriate), and use the equivalent of
> --disable-apparmor for any feature we don't (yet?) want to enable.

Right.  ISTM that it would be a bug if this was not done, which is why
it seems unwise to include Ian's (ii) in Policy.

-- 
Sean Whitton


signature.asc
Description: PGP signature

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

[Simon McVittie]

On Sat, 10 Nov 2018 at 19:29:03 -0700, Sean Whitton wrote:
> On Thu 08 Nov 2018 at 02:51PM GMT, Ian Jackson wrote:
> >(ii) output packages with additional features or functionality.
> >Such additional features MAY imply additional functional runtime
> >dependencies, which then SHOULD be represented in the output
> >packages' metadata.  In this case the additional packages
> >SHOULD NOT be declared in Build-Conflicts.
> 
> Do we really want (ii)?  It seems like a recipe for all sorts of
> confusion.  Do any packages currently work like that?

I don't have any concrete examples, and I'd argue that they are not
best-practice, but they almost certainly exist in the archive.

This will happen whenever an Autoconf package has a feature enabled by an
"automagic" dependency, the maintainer has not enabled the feature for all
Debian users by adding its required package to B-D or explicitly enabling
it with --with-foo or --enable-foo (either deliberately, or because they
didn't notice the feature being added), and the maintainer has also not
explicitly disabled it with --without-foo or --disable-foo.

For instance, dbus has optional support for using AppArmor policy to
decide which messages to deliver. If its maintainer hadn't noticed that
feature being added, then it wouldn't have B-D: libapparmor-dev or
./configure --enable-apparmor, but it also wouldn't have
./configure --disable-apparmor, resulting in the upstream default
behaviour (AppArmor-related features enabled if and only if
libapparmor-dev is installed).

I think the best practice is for maintainers to notice new features being
added, make a deliberate decision on what to enable (in an architecture-
or kernel-specific way if appropriate), and use the equivalent of
--disable-apparmor for any feature we don't (yet?) want to enable.

smcv

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

[Sean Whitton]

Hello,

On Thu 08 Nov 2018 at 02:51PM GMT, Ian Jackson wrote:

> How about:
>
>   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  EffectPermitted
>on build output
>
> Installed by default   Any effectMUST NOT
> with any Build-Depends

"Installed by default" defers to apt's opinion of what gets installed by
default.  Policy should probably not do that, so we should refers to
Depends and Recommends.

> Part of any reasonble  AdditionalSHOULD NOT
> default install for features
> development workstation
>Build fails   SHOULD NOT,
>MUST Build-Conflict
>
>Builds broken MUST NOT
>packages
>
> Other packages AdditionalMAY
> features
>
>Build fails   SHOULD NOT,
>MUST Build-Conflict
>
>Builds broken MUST NOT
>packages
>
> Or to put it another way:
>
>  Package builds MAY be influenced by the presence in the build
>  environment of additional packages, beyond the Build-Depends and
>  build-essential.  However:
>
>  Additional packages MUST NOT have any effect other than either:
>
>(i) a failure of the build, in which case the additional packages
>MUST be declared in Build-Conflicts); or
>
>(ii) output packages with additional features or functionality.
>Such additional features MAY imply additional functional runtime
>dependencies, which then SHOULD be represented in the output
>packages' metadata.  In this case the additional packages
>SHOULD NOT be declared in Build-Conflicts.
>
>  Additionally, in any case: additional packages which are installed by
>  default by apt when the build dependencies are installed MUST NOT
>  have any significant effect.

Do we really want (ii)?  It seems like a recipe for all sorts of
confusion.  Do any packages currently work like that?

In order to implement something like this, we'd need to rebuild the
archive on a "development workstation" to confirm we weren't making a
lot of packages RC-buggy.  (It is not clear to me that such packages
would be considered by most Debian participants to be RC-buggy in
advance of a Policy change like this one being proposed.)

-- 
Sean Whitton


signature.asc
Description: PGP signature

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

[Sean Whitton]

Hello,

On Sun 04 Nov 2018 at 12:38AM +0100, Santiago Vila wrote:

> Maybe the relevant paragraph in policy is this one instead:
>
>   If build-time dependencies are specified, it must be possible to build
>   the package and produce working binaries on a system with only
>   essential and build-essential packages installed and also those
>   required to satisfy the build-time relationships (including any
>   implied relationships).
>
> To follow with the previous example, does this paragraph imply that if
> you call automake by "automake" and you build-depend on automake-1.11
> then you should use a build-conflict?
>
> I don't think so, because the "with only [...]" part suggests the
> completely minimal chroot approach to building packages.

Actually, I think this paragraph *does* entail that you should use
Build-Conflicts, if we consider Build-Conflicts to be included in
"build-time dependencies" (out of context, ISTM we should).

In your case, before the package added Build-Conflicts, it was not
possible to build the package when essential and build-essential were
installed, and the build-time dependencies specified by the package were
satisfied.  So this requirement was being violated.

Once Build-Conflicts was added, the package no longer violated this
requirement.  That's because satisfying the build-time dependencies
means removing automake.

-- 
Sean Whitton


signature.asc
Description: PGP signature

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

[Santiago Vila]

On Thu, Nov 08, 2018 at 02:51:55PM +, Ian Jackson wrote:

> [...]

Looks ok at first read, maybe a little bit too much normative.

One minor comment:

>   (i) a failure of the build, in which case the additional packages
>  MUST be declared in Build-Conflicts);

As we talked before, that's usually a required workaround but often
not the best solution. I would try to complement the quoted paragraph
with some note or advice saying "try to make it compatible so that
build-conflicts are not really required" or something alike.

Thanks.

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

[Ian Jackson]

Russ Allbery writes ("Bug#824495: debian-policy: Source packages "can" declare 
relationships"):
> I feel pretty strongly here that Build-Conflicts is not a correct solution
> to this problem, and therefore I'm not happy about the idea of adding a
> Policy rule that would imply that it was.  The problem was that the
> package didn't tolerate having automake installed, and fixing *that* was
> the correct fix.  But this seems fairly subtle to try to turn into a
> general Policy rule.

How about:

  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  EffectPermitted
   on build output

Installed by default   Any effectMUST NOT
with any Build-Depends

Part of any reasonble  AdditionalSHOULD NOT
default install for features
development workstation
   Build fails   SHOULD NOT,
 MUST Build-Conflict

   Builds broken MUST NOT
   packages

Other packages AdditionalMAY
features

   Build fails   SHOULD NOT,
 MUST Build-Conflict

   Builds broken MUST NOT
   packages

Or to put it another way:

 Package builds MAY be influenced by the presence in the build
 environment of additional packages, beyond the Build-Depends and
 build-essential.  However:

 Additional packages MUST NOT have any effect other than either:

   (i) a failure of the build, in which case the additional packages
   MUST be declared in Build-Conflicts); or

   (ii) output packages with additional features or functionality.
   Such additional features MAY imply additional functional runtime
   dependencies, which then SHOULD be represented in the output
   packages' metadata.  In this case the additional packages
   SHOULD NOT be declared in Build-Conflicts.

 Additionally, in any case: additional packages which are installed by
 default by apt when the build dependencies are installed MUST NOT
 have any significant effect.

 Any additional package which could reasonably form part of a default
 install for a development workstation SHOULD NOT have any significant
 effect.

Ian.


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

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

[Russ Allbery]

Santiago Vila  writes:
> On Sat, Nov 03, 2018 at 03:42:20PM -0700, Russ Allbery wrote:

>> In a way, I don't think this goes far enough.  Build-Conflicting with
>> something installed by debhelper would be incredibly painful and would
>> basically require the package be built in a chroot.

> I'm not sure what do you mean by "painful" here. In this case, a
> Build-Conflicts would have told sbuild to uninstall automake during
> the "install build-dependencies stage", which is not painful at all.

I certainly think it is!  I would be extremely upset if trying to build a
package uninstalled automake.

This also makes the package effectively unbuildable outside of a chroot,
which is also quite painful.

I feel pretty strongly here that Build-Conflicts is not a correct solution
to this problem, and therefore I'm not happy about the idea of adding a
Policy rule that would imply that it was.  The problem was that the
package didn't tolerate having automake installed, and fixing *that* was
the correct fix.  But this seems fairly subtle to try to turn into a
general Policy rule.

-- 
Russ Allbery (r...@debian.org)   

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

[Santiago Vila]

On Sat, Nov 03, 2018 at 03:42:20PM -0700, Russ Allbery wrote:

> In a way, I don't think this goes far enough.  Build-Conflicting with
> something installed by debhelper would be incredibly painful and would
> basically require the package be built in a chroot.

I'm not sure what do you mean by "painful" here. In this case, a
Build-Conflicts would have told sbuild to uninstall automake during
the "install build-dependencies stage", which is not painful at all.

The real pain comes from not having a build-conflicts at all (because
in such case there was a FTBFS).

> In this particular case, it also seems unnecessary. [...]

In this case, it was unnecessary, yes. The maintainer solved the
problem by calling automake-1.11 by its versioned name. But as far as
this was not done yet, the package had an undeclared build-conflicts.

Anyway, this was the case that made me think about the language used
in policy. The package (as it was) "required" in an absolute sense not
to have automake installed as much as it "required" to have their
build-dependencies installed. That's why "can" or "may" seemed a
little bit strange for the wording to me.

Maybe the relevant paragraph in policy is this one instead:

  If build-time dependencies are specified, it must be possible to build
  the package and produce working binaries on a system with only
  essential and build-essential packages installed and also those
  required to satisfy the build-time relationships (including any
  implied relationships).

To follow with the previous example, does this paragraph imply that if
you call automake by "automake" and you build-depend on automake-1.11
then you should use a build-conflict?

I don't think so, because the "with only [...]" part suggests the
completely minimal chroot approach to building packages.

Thanks.

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

[Russ Allbery]

Santiago Vila  writes:

> The source package failed to build from source if you had "automake"
> installed in the chroot. At the time, automake was installed by default
> when you installed debhelper.

Ow.

> So: What about "packages should declare Build-Conflicts when the
> build-conflict happens against a very common build-dependency"?
> (Or something like that).

In a way, I don't think this goes far enough.  Build-Conflicting with
something installed by debhelper would be incredibly painful and would
basically require the package be built in a chroot.

In this particular case, it also seems unnecessary.  automake1.11 is
(unless I'm missing something) co-installable with automake, so I think
the root problem here is that the package isn't using it in preference to
automake when both are installed.  This feels like something that should
be fixed in the package, not worked around by adding Build-Conflicts
against an incredibly commonly-installed package.

-- 
Russ Allbery (r...@debian.org)   

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

[Santiago Vila]

> > While we are at it, I understand, because it would involve a huge
> > amount of computation to determine, that we can't test every package
> > against every other binary package to discover undeclared
> > build-conflicts.
> 
> Well, indeed.  In fact, this is the reason why I don't see how we could
> introduce a requirement to use Build-Conflicts into Policy.  We would
> not be able to determine whether we were making packages buggy by doing
> that.

Sorry, I forgot some details about the case that prompted me to file
this report:

I was building all the packages in stretch, and to save time and
bandwidth for each build, I installed debhelper in my chroot
(as nearly every package uses it).

The source package failed to build from source if you had "automake"
installed in the chroot. At the time, automake was installed by
default when you installed debhelper.

So it built ok only if you take the ultraorthodox path of having a
completely minimal chroot, but it would fail for anybody who, like me,
also installed debhelper and its default dependencies in the chroot.

What I would like to avoid is maintainers recommending or even
*suggesting* the user to uninstall the conflicting package
as a way to "solve" the problem, as it happened here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824011

Maybe I was a little bit rude at the time by changing the severity
while discussing, but I would also consider rude that a maintainer
even suggests that this FTBFS problem is user's fault and not a
packaging bug.

So: What about "packages should declare Build-Conflicts when the
build-conflict happens against a very common build-dependency"?
(Or something like that).

If we don't do anything like that, not even a recommendation, an
example, or a typical use-case for build-conflicts, maybe we could
declare that the only acceptable way to build packages is to have a
completely minimal chroot and declare build-conflicts obsolete...

Thanks.

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

[Debian Bug Tracking System]

Processing control commands:

> tag -1 +pending
Bug #824495 [debian-policy] debian-policy: Source packages "can" declare 
relationships
Added tag(s) pending.

-- 
824495: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824495
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

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

[Sean Whitton]

control: tag -1 +pending

Hello Santiago,

On Mon 16 May 2016 at 08:16PM +0200, Santiago Vila wrote:

> Policy 7.7 says: (Bold in "can" is mine)
>
>   Source packages that require certain binary packages to be installed
>   or absent at the time of building the package *can* declare
>   relationships to those binary packages.
>
> I interpret this "can" in the sense that this is the vocabulary that
> the maintainer is allowed to use when writing control files.
>
> To my surprise, however, today a maintainer has quoted this "can" word
> as a rationale for a missing Build-Conflicts not to be a bug of serious
> severity:
>
>   "No _must_ directive here. It is not a Policy violation if you don't
>   use Build-Conflicts."

This maintainer's interpretation matches how I'd understand the quoted
wording from 7.7.

> If my idea that policy is just describing the vocabulary is close to
> reality, I would perhaps suggest something like this:
>
>   The following relationsips are available for source packages to
>   express the fact that they require certain binary packages to be
>   installed or absent at the time of building the package.

I tried implementing something like this wording, but I don't think it
reads any better, when considered as part of the section as a whole.

What I've done instead is replace 'can' with 'may', which is the
standard Policy language to express that things are optional.

> but then it would be nice to state somewhere later that Build-Depends
> and Build-Conflicts are not just "optional" but mandatory when the
> referenced packages are either required to be present or required to
> be absent.
>
>
> While we are at it, I understand, because it would involve a huge
> amount of computation to determine, that we can't test every package
> against every other binary package to discover undeclared
> build-conflicts.

Well, indeed.  In fact, this is the reason why I don't see how we could
introduce a requirement to use Build-Conflicts into Policy.  We would
not be able to determine whether we were making packages buggy by doing
that.

Thus, I'm marking this bug as done with the s/can/may/ change, since I
don't think the normative change is one we can feasibly make.

-- 
Sean Whitton


signature.asc
Description: PGP signature

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

[Santiago Vila]

Package: debian-policy
Severity: wishlist

Hello.

Policy 7.7 says: (Bold in "can" is mine)

  Source packages that require certain binary packages to be installed
  or absent at the time of building the package *can* declare
  relationships to those binary packages.

I interpret this "can" in the sense that this is the vocabulary that
the maintainer is allowed to use when writing control files.

To my surprise, however, today a maintainer has quoted this "can" word
as a rationale for a missing Build-Conflicts not to be a bug of serious
severity:

  "No _must_ directive here. It is not a Policy violation if you don't
  use Build-Conflicts."

If my idea that policy is just describing the vocabulary is close to
reality, I would perhaps suggest something like this:

  The following relationsips are available for source packages to
  express the fact that they require certain binary packages to be
  installed or absent at the time of building the package.

but then it would be nice to state somewhere later that Build-Depends
and Build-Conflicts are not just "optional" but mandatory when the
referenced packages are either required to be present or required to
be absent.


While we are at it, I understand, because it would involve a huge
amount of computation to determine, that we can't test every package
against every other binary package to discover undeclared
build-conflicts.

Is there any rule to decide what to put in build-conflicts?

Thanks.