Debian Bug report logs - #218893
Add Build-Options control field

version graph

Package: debian-policy; Maintainer for debian-policy is Debian Policy List <debian-policy@lists.debian.org>; Source for debian-policy is src:debian-policy.

Reported by: Bill Allombert <allomber@math.u-bordeaux.fr>

Date: Mon, 3 Nov 2003 09:03:03 UTC

Severity: wishlist

Found in version 3.6.1

Reply or subscribe to this bug.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Bill Allombert <allomber@math.u-bordeaux.fr>:
New Bug report received and forwarded. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Bill Allombert <allomber@math.u-bordeaux.fr>
To: submit@bugs.debian.org
Subject: Proposal: debian/rules.version file [Fix for the build-arch problem]
Date: Mon, 3 Nov 2003 09:59:24 +0100
[Message part 1 (text/plain, inline)]
Package: debian-policy
Version: 3.6.1

Hello Debian policy,

I would like to fix the problem with Build-Depends-Indep and buid-arch
in current policy.

1) Background:

1.1) Current policy defines two optional debian/rules targets
'build-arch' and 'build-indep'.

1.2) Policy state that

          If one or both of the targets `build-arch' and `build-indep' are
          not provided, then invoking `debian/rules' with one of the
          not-provided targets as arguments should produce a exit status
          code of 2.  Usually this is provided automatically by make if the
          target is missing.

1.3) Dpkg developer Adam Heath tried to implement the recipe above in
dpkg-buildpackage but reverted it since it was broken. The problem is
that 'debian/rules build-arch' can produce an exit status code of 2 even
if the target is available. GNU make manual state that 

     The exit status is two if `make' encounters any errors.  It will
     print messages describing the particular errors.

1.4) dpkg-buildpackage -B call 'debian/rules build' and then
'debian/rules binary-arch'. Policy 7.6 mandate that both 'Build-Depends'
and 'Build-Depends-Indep' dependencies be satisfied when 'debian/rules
build' is called, making the split useless.

1.5) The buildd software only install Build-Depends and not
Build-Depends-Indep. Due to 1.4, this leads to build failures.

1.6) Policy 7.6 defines the Build-Depends/Build-Depends-Indep split in
term of use of debian/rules target, not in term of which kind of packages are 
to be build (i.e. Arch: any or all).

2) Analysis

There are several problems intertwined here:

2.1) The recipe given in policy to detect whether optional targets are
available is not reliable.

2.2) buildd make a false assumption on the behaviour of dpkg-buildpackage

2.3) Even if it were correct, it would not be correct due to 1.6: buildd
must know if build-arch is available to decide whether
Build-Depends-Indep need to be installed. Look at the following example:

  Package has both Build-Depends and Build-Depends-Indep, but no
  build-arch target. This is acceptable according to policy. However
  policy require that both Build-Depends and Build-Depends-Indep be
  installed when building binary-arch packages since the 'build' target
  will be called.

3) Solution:
3.1) Provide an easy and reliable way to tell if the optional targets 
are implemented.
3.2) Change dpkg-buildpackage to make use of this information
3.3) Change buildd to make use of this information.
( Though one could argue that buildd should not make assumption on
dpkg-buildpackage behaviour. )

Only 3.1 is relevant to policy.

I propose two alternative (attached, sorry for the SGML patches).

Choose one:

The first is to add a debian/rules.version with meaning:
debian/rules.version is present and is "1\n": build-arch and build-indep
are implemented

The second is to add a debian/rules.targets with the list of available
optional targets.

First solution is easier to implement.  Second one scale better but does not
allow to revoke the meaning of a target.

If you are going to second this proposal, please state if you prefer
debian/rules.version or debian/rules.targets.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 
[patch1 (text/plain, attachment)]
[patch2 (text/plain, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Josip Rodin <joy@srce.hr>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #10 received at 218893@bugs.debian.org (full text, mbox):

From: Josip Rodin <joy@srce.hr>
To: Bill Allombert <allomber@math.u-bordeaux.fr>, 218893@bugs.debian.org
Subject: Re: Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
Date: Mon, 3 Nov 2003 11:01:13 +0100
On Mon, Nov 03, 2003 at 09:59:24AM +0100, Bill Allombert wrote:
> 3.1) Provide an easy and reliable way to tell if the optional targets 
> are implemented.

And once that's there, clarify Policy to say what dpkg-buildpackage et al
will do: if optional targets are missing, do the old thing. If the optional
targets are there, do the new thing instead.

> The first is to add a debian/rules.version with meaning:
> debian/rules.version is present and is "1\n": build-arch and build-indep
> are implemented
> 
> The second is to add a debian/rules.targets with the list of available
> optional targets.
> 
> First solution is easier to implement.  Second one scale better but does
> not allow to revoke the meaning of a target.

Well, regardless of whether we pick versions or listing available targets,
why not do it with a new control file field in the source section?
That seems logical, and avoids creating a new file.

It's tangentially relevant that the .dsc and .changes files include a Format
field that is a version number. Having a "Rules-Format: 2" field in control
seems okay to me.

-- 
     2. That which causes joy or happiness.



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Andreas Metzler <ametzler@downhill.at.eu.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #15 received at 218893@bugs.debian.org (full text, mbox):

From: Andreas Metzler <ametzler@downhill.at.eu.org>
To: 218893@bugs.debian.org
Subject: Re: Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
Date: Mon, 3 Nov 2003 11:01:14 +0100
[Message part 1 (text/plain, inline)]
On Mon, Nov 03, 2003 at 09:59:24AM +0100, Bill Allombert wrote:
> 1.3) Dpkg developer Adam Heath tried to implement the recipe above in
> dpkg-buildpackage but reverted it since it was broken. 
[...]

See changelog for 1.10.15.

> 1.4) dpkg-buildpackage -B call 'debian/rules build' and then
> 'debian/rules binary-arch'. Policy 7.6 mandate that both 'Build-Depends'
> and 'Build-Depends-Indep' dependencies be satisfied when 'debian/rules
> build' is called, making the split useless.
[...]

For a recent example see Bug#216492 and
 Subject: Re: Bug#216492: FTBFS (unstable/all) missing build-dep
 From: Scott James Remnant <scott@netsplit.com>
 Cc: Debian Developers <debian-devel@lists.debian.org>
 Message-ID: <1066566039.2228.24.camel@descent.netsplit.com>
 Date: Sun, 19 Oct 2003 13:20:39 +0100

I am waiting for comments by more knowledgeable people than
myself before seconding the proposal, I assume
dpkg-buildpackage support should better be implemented and distributed
_before_ changing policy. But this requires that one or the other of
your alternatives is chosen first.

        cu andreas
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Bill Allombert <allomber@math.u-bordeaux.fr>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #20 received at 218893@bugs.debian.org (full text, mbox):

From: Bill Allombert <allomber@math.u-bordeaux.fr>
To: 218893@bugs.debian.org
Subject: Re: Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
Date: Mon, 3 Nov 2003 11:57:51 +0100
On Mon, Nov 03, 2003 at 11:01:13AM +0100, Josip Rodin wrote:
> On Mon, Nov 03, 2003 at 09:59:24AM +0100, Bill Allombert wrote:
> > 3.1) Provide an easy and reliable way to tell if the optional targets 
> > are implemented.
> 
> And once that's there, clarify Policy to say what dpkg-buildpackage et al
> will do: if optional targets are missing, do the old thing. If the optional
> targets are there, do the new thing instead.

... so that buildd will rely on dpkg-buildpackage behaviour documented 
by policy.  OK for me.

> > The first is to add a debian/rules.version with meaning:
> > debian/rules.version is present and is "1\n": build-arch and build-indep
> > are implemented
> > 
> > The second is to add a debian/rules.targets with the list of available
> > optional targets.
> > 
> > First solution is easier to implement.  Second one scale better but does
> > not allow to revoke the meaning of a target.
> 
> Well, regardless of whether we pick versions or listing available targets,
> why not do it with a new control file field in the source section?
> That seems logical, and avoids creating a new file.
> 
> It's tangentially relevant that the .dsc and .changes files include a Format
> field that is a version number. Having a "Rules-Format: 2" field in control
> seems okay to me.

Some packages generate the control file at build time (e.g. from a
control.in).  We need to access the file before debian/rules is used,
and debian/control might not exist yet.

Cheers,
Bill.



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Colin Watson <cjwatson@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #25 received at 218893@bugs.debian.org (full text, mbox):

From: Colin Watson <cjwatson@debian.org>
To: Bill Allombert <allomber@math.u-bordeaux.fr>, 218893@bugs.debian.org
Subject: Re: Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
Date: Mon, 3 Nov 2003 11:21:55 +0000
On Mon, Nov 03, 2003 at 11:57:51AM +0100, Bill Allombert wrote:
> On Mon, Nov 03, 2003 at 11:01:13AM +0100, Josip Rodin wrote:
> > Well, regardless of whether we pick versions or listing available targets,
> > why not do it with a new control file field in the source section?
> > That seems logical, and avoids creating a new file.
> > 
> > It's tangentially relevant that the .dsc and .changes files include a Format
> > field that is a version number. Having a "Rules-Format: 2" field in control
> > seems okay to me.
> 
> Some packages generate the control file at build time (e.g. from a
> control.in).  We need to access the file before debian/rules is used,
> and debian/control might not exist yet.

dpkg-source already requires debian/control to exist before it calls the
rules file, so packages already have to make sure debian/control exists
in their source package, even if they later change it.

Cheers,

-- 
Colin Watson                                  [cjwatson@flatline.org.uk]



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Josip Rodin <joy@srce.hr>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #30 received at 218893@bugs.debian.org (full text, mbox):

From: Josip Rodin <joy@srce.hr>
To: Bill Allombert <allomber@math.u-bordeaux.fr>, 218893@bugs.debian.org
Subject: Re: Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
Date: Mon, 3 Nov 2003 12:31:30 +0100
On Mon, Nov 03, 2003 at 11:57:51AM +0100, Bill Allombert wrote:
> Some packages generate the control file at build time (e.g. from a
> control.in).  We need to access the file before debian/rules is used,
> and debian/control might not exist yet.

AFAIK they all have the source section, they only autogenerate the binary
sections.

I somehow doubt that a package without any debian/control whatsoever upon
extraction is valid at all.

-- 
     2. That which causes joy or happiness.



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Santiago Vila <sanvila@unex.es>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #35 received at 218893@bugs.debian.org (full text, mbox):

From: Santiago Vila <sanvila@unex.es>
To: 218893@bugs.debian.org
Subject: Re: Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
Date: Mon, 3 Nov 2003 12:36:15 +0100 (CET)
I object to making the packaging system more complex without a real gain.

We should better document what "Build-Depends-Indep:" really mean:
That which autobuilders do not need to install to produce Architecture: any
packages via the clean, build and binary-arch targets only.

We could well keep Build-Depends-Indep: for things which are only used
by the binary-indep target (which is how things really work today),
and deprecate the build-arch and build-indep targets, since they have
never been really useful.



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Bill Allombert <allomber@math.u-bordeaux.fr>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #40 received at 218893@bugs.debian.org (full text, mbox):

From: Bill Allombert <allomber@math.u-bordeaux.fr>
Cc: 218893@bugs.debian.org
Subject: Re: Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
Date: Mon, 3 Nov 2003 13:01:07 +0100
On Mon, Nov 03, 2003 at 11:21:55AM +0000, Colin Watson wrote:
> dpkg-source already requires debian/control to exist before it calls the
> rules file, so packages already have to make sure debian/control exists
> in their source package, even if they later change it.

Ok, so I retract my objection. Joy, would you mind submit a patch 
that implement your proposal ?

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Josip Rodin <joy@srce.hr>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #45 received at 218893@bugs.debian.org (full text, mbox):

From: Josip Rodin <joy@srce.hr>
To: 218893@bugs.debian.org
Subject: Re: Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
Date: Mon, 3 Nov 2003 13:11:57 +0100
On Mon, Nov 03, 2003 at 12:36:15PM +0100, Santiago Vila wrote:
> I object to making the packaging system more complex without a real gain.
> 
> We should better document what "Build-Depends-Indep:" really mean:
> That which autobuilders do not need to install to produce Architecture: any
> packages via the clean, build and binary-arch targets only.

Without having functional, separate rules for building Arch: all packages,
there is limited gain in doing this.

> We could well keep Build-Depends-Indep: for things which are only used
> by the binary-indep target (which is how things really work today),
> and deprecate the build-arch and build-indep targets, since they have
> never been really useful.

The external dependencies are more often used in the build rules, rather
than the binary rules, I would think. Then again, maybe not. How about we
have someone collect some statistics? Have we had any statistics provided
back when this stuff initially entered the Policy manual?

-- 
     2. That which causes joy or happiness.



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Bill Allombert <allomber@math.u-bordeaux.fr>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #50 received at 218893@bugs.debian.org (full text, mbox):

From: Bill Allombert <allomber@math.u-bordeaux.fr>
To: Santiago Vila <sanvila@unex.es>, 218893@bugs.debian.org
Subject: Re: Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
Date: Mon, 3 Nov 2003 13:36:40 +0100
On Mon, Nov 03, 2003 at 12:36:15PM +0100, Santiago Vila wrote:
> I object to making the packaging system more complex without a real gain.
> 
> We should better document what "Build-Depends-Indep:" really mean:
> That which autobuilders do not need to install to produce Architecture: any
> packages via the clean, build and binary-arch targets only.

The alternative is to mandate that packages with a Build-Depends-Indep: field
MUST implement build-arch and build-indep.

> We could well keep Build-Depends-Indep: for things which are only used
> by the binary-indep target (which is how things really work today),
> and deprecate the build-arch and build-indep targets, since they have
> never been really useful.

Because they were not working ?

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Julian Gilbey <jdg@polya.uklinux.net>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #55 received at 218893@bugs.debian.org (full text, mbox):

From: Julian Gilbey <jdg@polya.uklinux.net>
To: Josip Rodin <joy@srce.hr>, 218893@bugs.debian.org
Cc: Bill Allombert <allomber@math.u-bordeaux.fr>
Subject: Re: Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
Date: Mon, 3 Nov 2003 12:59:03 +0000
On Mon, Nov 03, 2003 at 11:01:13AM +0100, Josip Rodin wrote:
> On Mon, Nov 03, 2003 at 09:59:24AM +0100, Bill Allombert wrote:
> > 3.1) Provide an easy and reliable way to tell if the optional targets 
> > are implemented.
> 
> And once that's there, clarify Policy to say what dpkg-buildpackage et al
> will do: if optional targets are missing, do the old thing. If the optional
> targets are there, do the new thing instead.

No, can't do that!  There is no way to test for the presence of
optional targets!  (That's why this whole proposal was suggested.)

So it would be something like:

rules-version=0
  required targets: build, binary-arch, binary-indep, binary, clean

rules-version=1
  additional required targets: build-arch, build-indep

rules-version=2
  additional required targets: ...

etc.

   Julian

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

        Julian Gilbey, website: http://www.polya.uklinux.net/
   Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/
     Visit http://www.thehungersite.com/ to help feed the hungry



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Julian Gilbey <jdg@polya.uklinux.net>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #60 received at 218893@bugs.debian.org (full text, mbox):

From: Julian Gilbey <jdg@polya.uklinux.net>
To: Josip Rodin <joy@srce.hr>, 218893@bugs.debian.org
Cc: Bill Allombert <allomber@math.u-bordeaux.fr>
Subject: Re: Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
Date: Mon, 3 Nov 2003 13:04:38 +0000
On Mon, Nov 03, 2003 at 11:01:13AM +0100, Josip Rodin wrote:
> On Mon, Nov 03, 2003 at 09:59:24AM +0100, Bill Allombert wrote:
> > 3.1) Provide an easy and reliable way to tell if the optional targets 
> > are implemented.
> 
> And once that's there, clarify Policy to say what dpkg-buildpackage et al
> will do: if optional targets are missing, do the old thing. If the optional
> targets are there, do the new thing instead.

Oh, I just misparsed this when I replied last time.  I think what you
mean is:

if rules.version=0, then dpkg-buildpackage behaviour will be ...
if rules.version=1, then dpkg-buildpackage will be allowed to do ...
etc.

But of course, this has to be done with the consent and coorperation
of the dpkg maintainers.

   Julian

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

        Julian Gilbey, website: http://www.polya.uklinux.net/
   Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/
     Visit http://www.thehungersite.com/ to help feed the hungry



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Andreas Metzler <ametzler@logic.univie.ac.at>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #65 received at 218893@bugs.debian.org (full text, mbox):

From: Andreas Metzler <ametzler@logic.univie.ac.at>
To: 218893@bugs.debian.org
Subject: Re: Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
Date: Mon, 3 Nov 2003 14:10:11 +0100
On Mon, Nov 03, 2003 at 12:59:03PM +0000, Julian Gilbey wrote:
> On Mon, Nov 03, 2003 at 11:01:13AM +0100, Josip Rodin wrote:
> > On Mon, Nov 03, 2003 at 09:59:24AM +0100, Bill Allombert wrote:
> > > 3.1) Provide an easy and reliable way to tell if the optional targets 
> > > are implemented.

> > And once that's there, clarify Policy to say what
> > dpkg-buildpackage et al will do: if optional targets are missing,
> > do the old thing. If the optional targets are there, do the new
> > thing instead.
 
> No, can't do that!  There is no way to test for the presence of
> optional targets!  (That's why this whole proposal was suggested.)
[...]

Please reread what you replied to.

BA> Provide way to tell if the optional targets are implemented

JS> And once that's there
    ^^^^^^^^^^^^^^^^^^^^

             cu andreas



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Josip Rodin <joy@srce.hr>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #70 received at 218893@bugs.debian.org (full text, mbox):

From: Josip Rodin <joy@srce.hr>
To: 218893@bugs.debian.org
Subject: Re: Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
Date: Mon, 3 Nov 2003 17:20:42 +0100
On Mon, Nov 03, 2003 at 01:04:38PM +0000, Julian Gilbey wrote:
> > > 3.1) Provide an easy and reliable way to tell if the optional targets 
> > > are implemented.
> > 
> > And once that's there, clarify Policy to say what dpkg-buildpackage et al
> > will do: if optional targets are missing, do the old thing. If the optional
> > targets are there, do the new thing instead.
> 
> Oh, I just misparsed this when I replied last time.  I think what you
> mean is:
> 
> if rules.version=0, then dpkg-buildpackage behaviour will be ...
> if rules.version=1, then dpkg-buildpackage will be allowed to do ...
> etc.
> 
> But of course, this has to be done with the consent and coorperation
> of the dpkg maintainers.

Yes. Which is what we should have done the first time around!

-- 
     2. That which causes joy or happiness.



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Adam Heath <doogie@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #75 received at 218893@bugs.debian.org (full text, mbox):

From: Adam Heath <doogie@debian.org>
To: Bill Allombert <allomber@math.u-bordeaux.fr>, <218893@bugs.debian.org>
Subject: Re: Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
Date: Mon, 3 Nov 2003 10:38:34 -0600 (CST)
On Mon, 3 Nov 2003, Bill Allombert wrote:

> Some packages generate the control file at build time (e.g. from a
> control.in).  We need to access the file before debian/rules is used,
> and debian/control might not exist yet.

debian/rules clean is called very early, and is where debian/control is
usually generated.




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Adam Heath <doogie@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #80 received at 218893@bugs.debian.org (full text, mbox):

From: Adam Heath <doogie@debian.org>
To: Santiago Vila <sanvila@unex.es>, <218893@bugs.debian.org>
Subject: Re: Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
Date: Mon, 3 Nov 2003 10:43:47 -0600 (CST)
On Mon, 3 Nov 2003, Santiago Vila wrote:

> I object to making the packaging system more complex without a real gain.

Well, without adding complexity, I do agree to having a field that specifies
the calling procedure for building the package.  However, I don't like
Rules-Format, as it ties us to debian/rules.  How about Interface-Format?
It's a more general term, and defines the interface used to actually build the
package.

Once we have a field for specifying the interface for building a
package(which, on it's own, is very useful), decided what interfaces to
support is another topic.




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Santiago Vila <sanvila@unex.es>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #85 received at 218893@bugs.debian.org (full text, mbox):

From: Santiago Vila <sanvila@unex.es>
To: 218893@bugs.debian.org
Subject: Re: Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
Date: Mon, 3 Nov 2003 18:09:46 +0100 (CET)
On Mon, 3 Nov 2003, Adam Heath wrote:

> On Mon, 3 Nov 2003, Santiago Vila wrote:
>
> > I object to making the packaging system more complex without a real gain.
>
> Well, without adding complexity, I do agree to having a field that specifies
> the calling procedure for building the package.

Exactly. Which means having several different calling procedures.

What are the real benefits from having build-arch and build-indep?
Are there really so many packages which would benefit from having them?

(Remember "debug" in DEB_BUILD_OPTIONS? It was removed because its low
ratio benefit/cost).



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Bill Allombert <allomber@math.u-bordeaux.fr>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #90 received at 218893@bugs.debian.org (full text, mbox):

From: Bill Allombert <allomber@math.u-bordeaux.fr>
To: 218893@bugs.debian.org
Subject: Re: Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
Date: Mon, 3 Nov 2003 18:32:55 +0100
On Mon, Nov 03, 2003 at 06:09:46PM +0100, Santiago Vila wrote:
> What are the real benefits from having build-arch and build-indep?
> Are there really so many packages which would benefit from having them?
> 
> (Remember "debug" in DEB_BUILD_OPTIONS? It was removed because its low
> ratio benefit/cost).

It was made the default and replaced by a 'nostrip' option. It is
completly different from removed.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Santiago Vila <sanvila@unex.es>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #95 received at 218893@bugs.debian.org (full text, mbox):

From: Santiago Vila <sanvila@unex.es>
To: 218893@bugs.debian.org
Subject: Re: Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
Date: Mon, 3 Nov 2003 19:49:05 +0100 (CET)
On Mon, 3 Nov 2003, Bill Allombert wrote:

> On Mon, Nov 03, 2003 at 06:09:46PM +0100, Santiago Vila wrote:
> > What are the real benefits from having build-arch and build-indep?
> > Are there really so many packages which would benefit from having them?
> >
> > (Remember "debug" in DEB_BUILD_OPTIONS? It was removed because its low
> > ratio benefit/cost).
>
> It was made the default and replaced by a 'nostrip' option. It is
> completly different from removed.

That we introduced nostrip nearly at the same time we dropped debug
does not mean nostrip "replaces" debug. They have different meanings.

The fact is that before, we had an option to determine whether
or not -g had to be used, and now, we always compile using -g.

This decision was made after considering the real benefit of compiling
without -g (negligible according to people who did some tests).

I would call that a wise simplification.


For the same reason I would like to see the real benefits from
changing the format of debian/rules.



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to "Bernhard R. Link" <brl@pcpool00.mathematik.uni-freiburg.de>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #100 received at 218893@bugs.debian.org (full text, mbox):

From: "Bernhard R. Link" <brl@pcpool00.mathematik.uni-freiburg.de>
To: 218893@bugs.debian.org
Subject: Re: Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
Date: Mon, 3 Nov 2003 20:25:13 +0100
* Santiago Vila <sanvila@unex.es> [031103 18:19]:
> What are the real benefits from having build-arch and build-indep?
> Are there really so many packages which would benefit from having them?

The real benefit is that it makes it possible to really use
Build-Indeps, that most multi-binary-packages need to build
arch-independent documentation only once. (Compiling XFree on
some small machine for example already hard enough a task, even
without the hour needed for installing all the build-dependencies
for the documentation...) Not to speak about easier bootstrapping
of new arches and such things...

Hochachtungsvoll,
	Bernhard R. Link
-- 
The man who trades freedom for security does not deserve 
nor will he ever receive either. (Benjamin Franklin)



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Andreas Metzler <ametzler@downhill.at.eu.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #105 received at 218893@bugs.debian.org (full text, mbox):

From: Andreas Metzler <ametzler@downhill.at.eu.org>
To: 218893@bugs.debian.org
Subject: Re: Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
Date: Mon, 3 Nov 2003 20:51:58 +0100
On Mon, Nov 03, 2003 at 07:49:05PM +0100, Santiago Vila wrote:
> On Mon, 3 Nov 2003, Bill Allombert wrote:

> > On Mon, Nov 03, 2003 at 06:09:46PM +0100, Santiago Vila wrote:
> > > What are the real benefits from having build-arch and build-indep?
> > > Are there really so many packages which would benefit from having them?
[...]
> For the same reason I would like to see the real benefits from
> changing the format of debian/rules.

Did you miss the original subject of the thread? The benefit of the
proposal is to make the split Build-Depends-(Indep) useful at all[1].
Currently it is not, because the autobuilders invoke the build target,
which in turn invokes build-arch and build-indep, so you have to put
anything needed for building in Build-Depends, as the autobuilders
will uselessly build the build-indep target.

The -indep targets can be rather expensive, executing tex and other
stuff and requiing installing rather big packages.

I might be misunderstanding you, and you are actually asking for a
list of packages that would benefit from the proposal. - I don't think
that is easy to generate, as it requires checking debian/rules by
hand, we have just libtool as example.
        cu andreas
[1] Currently this is only possible with ugliness like making
build-indep an empty target and doing the actual expensive work in
binary-indep, or ignoring policy's recommendation to make build depend
on build-arch and build-indep.
-- 
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Josip Rodin <joy@srce.hr>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #110 received at 218893@bugs.debian.org (full text, mbox):

From: Josip Rodin <joy@srce.hr>
To: Bill Allombert <allomber@math.u-bordeaux.fr>, 218893@bugs.debian.org
Subject: Re: Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
Date: Mon, 3 Nov 2003 21:00:56 +0100
On Mon, Nov 03, 2003 at 06:32:55PM +0100, Bill Allombert wrote:
> On Mon, Nov 03, 2003 at 06:09:46PM +0100, Santiago Vila wrote:
> > What are the real benefits from having build-arch and build-indep?
> > Are there really so many packages which would benefit from having them?
> > 
> > (Remember "debug" in DEB_BUILD_OPTIONS? It was removed because its low
> > ratio benefit/cost).
> 
> It was made the default and replaced by a 'nostrip' option.

Actually that was noopt. nostrip coexisted with debug.

-- 
     2. That which causes joy or happiness.



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Santiago Vila <sanvila@unex.es>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #115 received at 218893@bugs.debian.org (full text, mbox):

From: Santiago Vila <sanvila@unex.es>
To: 218893@bugs.debian.org
Subject: Re: Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
Date: Mon, 3 Nov 2003 23:35:48 +0100 (CET)
On Mon, 3 Nov 2003, Andreas Metzler wrote:

> On Mon, Nov 03, 2003 at 07:49:05PM +0100, Santiago Vila wrote:
> > [...] I would like to see the real benefits from
> > changing the format of debian/rules.
>
> Did you miss the original subject of the thread? The benefit of the
> proposal is to make the split Build-Depends-(Indep) useful at all[1].
> Currently it is not, because the autobuilders invoke the build target,
> which in turn invokes build-arch and build-indep, so you have to put
> anything needed for building in Build-Depends, as the autobuilders
> will uselessly build the build-indep target.
>
> The -indep targets can be rather expensive, executing tex and other
> stuff and requiing installing rather big packages.
>
> I might be misunderstanding you, and you are actually asking for a
> list of packages that would benefit from the proposal.

An estimation of the number, more than a list.

> - I don't think
> that is easy to generate, as it requires checking debian/rules by
> hand, we have just libtool as example.
>         cu andreas
> [1] Currently this is only possible with ugliness like making
> build-indep an empty target and doing the actual expensive work in
> binary-indep,

Some of the packages I maintain use texi2html in the binary-indep
target (and they have texi2html in Build-Depends-Indep). Why is such
thing an ugliness? It is because it runs under root/fakeroot or are
there any other reason?

> or ignoring policy's recommendation to make build depend
> on build-arch and build-indep.

Which is what I would call complexity for very little gain.

Packages which do not benefit from a split build-arch / build-indep
(and there are certainly a lot of packages which do not benefit)
should continue to be allowed not to have such targets, without people
or policy saying they are following a "deprecated format" or anything
like that. Does this clarify my point?

What about optional fields in the control file with default values:

Build-Arch: build
Build-Indep: build

(and therefore may be omitted), but that can be overridden in this way?:

Build-Arch: build-arch
Build-Indep: build-indep

only for packages which really need or benefit from them?

(What I dislike is a "format version", mandatory conversion of all
packages to the new format in the long run, and all that).



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Bill Allombert <allomber@math.u-bordeaux.fr>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #120 received at 218893@bugs.debian.org (full text, mbox):

From: Bill Allombert <allomber@math.u-bordeaux.fr>
To: 218893@bugs.debian.org
Subject: Re: Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
Date: Tue, 4 Nov 2003 00:04:17 +0100
On Mon, Nov 03, 2003 at 11:35:48PM +0100, Santiago Vila wrote:
> What about optional fields in the control file with default values:
> 
> Build-Arch: build
> Build-Indep: build
> 
> (and therefore may be omitted), but that can be overridden in this way?:
> 
> Build-Arch: build-arch
> Build-Indep: build-indep
> 
> only for packages which really need or benefit from them?
> 
> (What I dislike is a "format version", mandatory conversion of all
> packages to the new format in the long run, and all that).

My proposal never called for that. In particular the rules.targets
option does not have this potential flaw by not creating a sense
that 'higher version is better'.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Josip Rodin <joy@srce.hr>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #125 received at 218893@bugs.debian.org (full text, mbox):

From: Josip Rodin <joy@srce.hr>
To: Santiago Vila <sanvila@unex.es>, 218893@bugs.debian.org
Subject: Re: Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
Date: Tue, 4 Nov 2003 00:10:19 +0100
On Mon, Nov 03, 2003 at 11:35:48PM +0100, Santiago Vila wrote:
> Packages which do not benefit from a split build-arch / build-indep
> (and there are certainly a lot of packages which do not benefit)
> should continue to be allowed not to have such targets, without people
> or policy saying they are following a "deprecated format" or anything
> like that. Does this clarify my point?

Sorry to be blunt, but what part of "if optional targets are missing, do the
old thing" did you not understand? I used this exact phrasing in the second
mail to the bug.

> (What I dislike is a "format version", mandatory conversion of all
> packages to the new format in the long run, and all that).

What mandatory conversion to the new format in the long run?

-- 
     2. That which causes joy or happiness.



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Santiago Vila <sanvila@unex.es>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #130 received at 218893@bugs.debian.org (full text, mbox):

From: Santiago Vila <sanvila@unex.es>
To: 218893@bugs.debian.org
Subject: Re: Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
Date: Tue, 4 Nov 2003 00:28:34 +0100 (CET)
On Tue, 4 Nov 2003, Bill Allombert wrote:

> On Mon, Nov 03, 2003 at 11:35:48PM +0100, Santiago Vila wrote:
> > What about optional fields in the control file with default values:
> >
> > Build-Arch: build
> > Build-Indep: build
> >
> > (and therefore may be omitted), but that can be overridden in this way?:
> >
> > Build-Arch: build-arch
> > Build-Indep: build-indep
> >
> > only for packages which really need or benefit from them?
> >
> > (What I dislike is a "format version", mandatory conversion of all
> > packages to the new format in the long run, and all that).
>
> My proposal never called for that. In particular the rules.targets
> option does not have this potential flaw by not creating a sense
> that 'higher version is better'.

Ok, no problem then.



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Bill Allombert <allomber@math.u-bordeaux.fr>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #135 received at 218893@bugs.debian.org (full text, mbox):

From: Bill Allombert <allomber@math.u-bordeaux.fr>
To: 218893@bugs.debian.org
Subject: Re: Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
Date: Tue, 4 Nov 2003 00:32:47 +0100
On Tue, Nov 04, 2003 at 12:10:19AM +0100, Josip Rodin wrote:
> > (What I dislike is a "format version", mandatory conversion of all
> > packages to the new format in the long run, and all that).
> 
> What mandatory conversion to the new format in the long run?

As I see it: currently there is version 0 and 1. Suppose one
day version 2 is added. Requirement for version 2 will include
requirement for version 1. If you want to implement version 2,
you will have to implement version 1 even if it is not useful,
say for a Arch: all source package.

However, if you don't need version 2, you can stay to version 0.

As a parallel, some of my packages are still using DH_COMPAT=1
debhelper interface, and no one is complaining.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Andreas Metzler <ametzler@downhill.at.eu.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #140 received at 218893@bugs.debian.org (full text, mbox):

From: Andreas Metzler <ametzler@downhill.at.eu.org>
To: 218893@bugs.debian.org
Subject: Re: Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
Date: Tue, 4 Nov 2003 09:06:55 +0100
On Mon, Nov 03, 2003 at 11:35:48PM +0100, Santiago Vila wrote:
> On Mon, 3 Nov 2003, Andreas Metzler wrote:
[...]
> > [1] Currently this is only possible with ugliness like making
> > build-indep an empty target and doing the actual expensive work in
> > binary-indep,

> Some of the packages I maintain use texi2html in the binary-indep
> target (and they have texi2html in Build-Depends-Indep). Why is such
> thing an ugliness? It is because it runs under root/fakeroot or are
> there any other reason?

Personal taste. ;-) iMvho it is obviously ugly, if the makefile has
build-indep and build-arch targets, I exspect that the time-consuming
activities are done in it.

But the real ugliness is that current policy propagates implementing
build-arch and build-indep target although they are useless. I _would_
really like to see either these two targets made useful (using
something like Bill's proposal) or to abolish mentioning/suggesting
them in policy.

> > or ignoring policy's recommendation to make build depend
> > on build-arch and build-indep.

> Which is what I would call complexity for very little gain.

> Packages which do not benefit from a split build-arch / build-indep
> (and there are certainly a lot of packages which do not benefit)

Ack, I am completely with you. (None of mine does.)

> should continue to be allowed not to have such targets, without people
> or policy saying they are following a "deprecated format" or anything
> like that. Does this clarify my point?

Yes. And I agree.  I just want the existing build-arch and
build-indep target made useful.

> What about optional fields in the control file with default values:

> Build-Arch: build
> Build-Indep: build

> (and therefore may be omitted), but that can be overridden in this way?:

> Build-Arch: build-arch
> Build-Indep: build-indep

> only for packages which really need or benefit from them?

> (What I dislike is a "format version", mandatory conversion of all
> packages to the new format in the long run, and all that).

That is equivalent to Bill's second proposal.

I get your point and support it.
                cu andreas
-- 
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Colin Watson <cjwatson@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #145 received at 218893@bugs.debian.org (full text, mbox):

From: Colin Watson <cjwatson@debian.org>
To: 218893@bugs.debian.org
Subject: Re: Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
Date: Tue, 4 Nov 2003 02:04:27 +0000
On Tue, Nov 04, 2003 at 12:32:47AM +0100, Bill Allombert wrote:
> On Tue, Nov 04, 2003 at 12:10:19AM +0100, Josip Rodin wrote:
> > What mandatory conversion to the new format in the long run?
> 
> As I see it: currently there is version 0 and 1. Suppose one
> day version 2 is added. Requirement for version 2 will include
> requirement for version 1. If you want to implement version 2,
> you will have to implement version 1 even if it is not useful,
> say for a Arch: all source package.
> 
> However, if you don't need version 2, you can stay to version 0.
> 
> As a parallel, some of my packages are still using DH_COMPAT=1
> debhelper interface, and no one is complaining.

Although I keep seeing inexperienced developers converting packages to
debhelper version 4 in NMUs. :-/ It's newer and shinier, so it must be
better, right? (And I wonder how many versioned build-deps on debhelper
go missing in the process, how many duplicate conffiles get created by
incautious moves to DH_COMPAT >= 3, and so on ... there's a reason we
discourage cosmetic changes in NMUs.)

If we're adding optional features, doing so in a way that doesn't
confuse people into believing that all packages need to use them would
definitely be a good thing, I think.

Cheers,

-- 
Colin Watson                                  [cjwatson@flatline.org.uk]



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Josip Rodin <joy@srce.hr>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #150 received at 218893@bugs.debian.org (full text, mbox):

From: Josip Rodin <joy@srce.hr>
To: 218893@bugs.debian.org
Subject: Re: Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
Date: Tue, 4 Nov 2003 12:15:09 +0100
On Tue, Nov 04, 2003 at 12:32:47AM +0100, Bill Allombert wrote:
> > > (What I dislike is a "format version", mandatory conversion of all
> > > packages to the new format in the long run, and all that).
> > 
> > What mandatory conversion to the new format in the long run?
> 
> As I see it: currently there is version 0 and 1.

I'd rather start with 1 being the current version (0 would indicate some
pre-production level, which it certainly isn't), but anyhow.

> Suppose one day version 2 is added. Requirement for version 2 will include
> requirement for version 1.

You don't necessarily know that.

-- 
     2. That which causes joy or happiness.



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Joey Hess <joeyh@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #155 received at 218893@bugs.debian.org (full text, mbox):

From: Joey Hess <joeyh@debian.org>
To: 218893@bugs.debian.org
Subject: Re: Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
Date: Tue, 4 Nov 2003 12:33:43 -0500
[Message part 1 (text/plain, inline)]
Josip Rodin wrote:
> Well, regardless of whether we pick versions or listing available targets,
> why not do it with a new control file field in the source section?
> That seems logical, and avoids creating a new file.
> 
> It's tangentially relevant that the .dsc and .changes files include a Format
> field that is a version number. Having a "Rules-Format: 2" field in control
> seems okay to me.

I agree that this would be the way to go (though I'm ambivilant about
the proposal).

-- 
see shy jo
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Josip Rodin <joy@srce.hr>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #160 received at 218893@bugs.debian.org (full text, mbox):

From: Josip Rodin <joy@srce.hr>
To: Colin Watson <cjwatson@debian.org>, 218893@bugs.debian.org
Subject: Re: Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
Date: Tue, 4 Nov 2003 18:34:23 +0100
On Tue, Nov 04, 2003 at 02:04:27AM +0000, Colin Watson wrote:
> It's newer and shinier, so it must be better, right?
> 
> If we're adding optional features, doing so in a way that doesn't
> confuse people into believing that all packages need to use them would
> definitely be a good thing, I think.

I agree that this may become a problem. Can you suggest a better way?
Maybe list tags within the new field rather than using a number?

-- 
     2. That which causes joy or happiness.



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Branden Robinson <branden@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #165 received at 218893@bugs.debian.org (full text, mbox):

From: Branden Robinson <branden@debian.org>
To: 218893@bugs.debian.org
Subject: Alternative proposal: debian/format
Date: Tue, 4 Nov 2003 13:03:48 -0500
[Message part 1 (text/plain, inline)]
On Mon, Nov 03, 2003 at 09:59:24AM +0100, Bill Allombert wrote:
> Choose one:
> 
> The first is to add a debian/rules.version with meaning:
> debian/rules.version is present and is "1\n": build-arch and build-indep
> are implemented
> 
> The second is to add a debian/rules.targets with the list of available
> optional targets.
> 
> First solution is easier to implement.  Second one scale better but does not
> allow to revoke the meaning of a target.
> 
> If you are going to second this proposal, please state if you prefer
> debian/rules.version or debian/rules.targets.

I like the general idea, but I prefer neither name.

Why are we attaching a versioning concept only to the rules file?

I think we should attach versioning to the entire layout of the unpacked
source package.

This gives us the flexibility to make other kinds of changes without
cluttering debian/ with still more files.

Consider a file debian/format:

$ cat debian/format
rules: 1
control: 2

The above tells dpkg that the package in question is using version 1 of
the debian/rules specification, and version 2 of the debian/control
specification.  (We could retroactively define version 2 of
debian/control as one that permits comments, for which dpkg recently
added support.)

The debian/format file can be extended arbitrarily to suit our needs.
We could change the format of a debian/changelog file with this
technique as well, if needed.

Of course, version 1 is assumed for everything in the absence of a
debian/format file.

Comments?

-- 
G. Branden Robinson                |    Lowery's Law:
Debian GNU/Linux                   |    If it jams -- force it.  If it
branden@debian.org                 |    breaks, it needed replacing anyway.
http://people.debian.org/~branden/ |
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Bill Allombert <allomber@math.u-bordeaux.fr>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #170 received at 218893@bugs.debian.org (full text, mbox):

From: Bill Allombert <allomber@math.u-bordeaux.fr>
To: 218893@bugs.debian.org
Subject: Re: Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
Date: Tue, 4 Nov 2003 19:05:29 +0100
On Tue, Nov 04, 2003 at 06:34:23PM +0100, Josip Rodin wrote:
> On Tue, Nov 04, 2003 at 02:04:27AM +0000, Colin Watson wrote:
> > It's newer and shinier, so it must be better, right?
> > 
> > If we're adding optional features, doing so in a way that doesn't
> > confuse people into believing that all packages need to use them would
> > definitely be a good thing, I think.
> 
> I agree that this may become a problem. Can you suggest a better way?
> Maybe list tags within the new field rather than using a number?

That would be a solution. Just find a tag that mean that
build-arch and build-indep are implemented, but shorter. Maybe
split_build.

And add
Build-Options: split_build
in debian/control.

Build-Options being a comma-separated lists of implemented options.

Though I start to wonder whether the original rules.targets proposal was
not cleaner.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Andreas Metzler <ametzler@downhill.at.eu.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #175 received at 218893@bugs.debian.org (full text, mbox):

From: Andreas Metzler <ametzler@downhill.at.eu.org>
To: 218893@bugs.debian.org
Subject: Re: Bug#218893: Alternative proposal: debian/format
Date: Wed, 5 Nov 2003 11:21:47 +0100
On Tue, Nov 04, 2003 at 01:03:48PM -0500, Branden Robinson wrote:
> On Mon, Nov 03, 2003 at 09:59:24AM +0100, Bill Allombert wrote:
> > Choose one:
> > 
> > The first is to add a debian/rules.version with meaning:
> > debian/rules.version is present and is "1\n": build-arch and build-indep
> > are implemented
> > 
> > The second is to add a debian/rules.targets with the list of available
> > optional targets.
[...]
> Why are we attaching a versioning concept only to the rules file?

> I think we should attach versioning to the entire layout of the unpacked
> source package.

> This gives us the flexibility to make other kinds of changes without
> cluttering debian/ with still more files.

> Consider a file debian/format:

> $ cat debian/format
> rules: 1
> control: 2

> The above tells dpkg that the package in question is using version 1 of
> the debian/rules specification, and version 2 of the debian/control
> specification.  (We could retroactively define version 2 of
> debian/control as one that permits comments, for which dpkg recently
> added support.)

> The debian/format file can be extended arbitrarily to suit our needs.
> We could change the format of a debian/changelog file with this
> technique as well, if needed.

> Of course, version 1 is assumed for everything in the absence of a
> debian/format file.

> Comments?

The main point against it is the one Santiago Vila brought up. Using a
number to describe whether debian/rules supports build-arch has the
flaw that it suggests that a package not implementing build-arch
supports _only_ version 1, and should be updated.

And this is wrong as the majority of the source-packages in the
Debian-archive don't produce binary-arch _and_ binary-all packages,
and implementing an (empty) build-arch (or build-all) target in
debian/rules serves no practical purpose for these packages, it is
just cruft.
                 cu andreas
-- 
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Adam Heath <doogie@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #180 received at 218893@bugs.debian.org (full text, mbox):

From: Adam Heath <doogie@debian.org>
To: 218893@bugs.debian.org
Subject: Re: Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
Date: Wed, 5 Nov 2003 14:03:17 -0600 (CST)
On Tue, 4 Nov 2003, Josip Rodin wrote:

> On Tue, Nov 04, 2003 at 02:04:27AM +0000, Colin Watson wrote:
> > It's newer and shinier, so it must be better, right?
> >
> > If we're adding optional features, doing so in a way that doesn't
> > confuse people into believing that all packages need to use them would
> > definitely be a good thing, I think.
>
> I agree that this may become a problem. Can you suggest a better way?
> Maybe list tags within the new field rather than using a number?

Instead of Rules-Version: in control, which specifies a single interface
'number', how about a Rules-Interface:, which contains a series of flags,
specifying what features are supported?

I leave it up to this list to decide what flags and what features get
enabled/disabled.




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Luca - De Whiskey's - De Vitis <luca@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #185 received at 218893@bugs.debian.org (full text, mbox):

From: Luca - De Whiskey's - De Vitis <luca@debian.org>
To: Adam Heath <doogie@debian.org>, 218893@bugs.debian.org, Branden Robinson <branden@debian.org>
Subject: Re: Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
Date: Wed, 5 Nov 2003 14:35:44 -0600
[Message part 1 (text/plain, inline)]
On Wed, Nov 05, 2003 at 02:03:17PM -0600, Adam Heath wrote:
> Instead of Rules-Version: in control, which specifies a single interface
> 'number', how about a Rules-Interface:, which contains a series of flags,
> specifying what features are supported?
> 
> I leave it up to this list to decide what flags and what features get
> enabled/disabled.

On Tue, Nov 04, 2003 at 01:03:48PM -0500, Branden Robinson wrote:
> I think we should attach versioning to the entire layout of the unpacked
> source package.
> 
> This gives us the flexibility to make other kinds of changes without
> cluttering debian/ with still more files.
> 
> Consider a file debian/format:
> 
> $ cat debian/format
> rules: 1
> control: 2
[...]

So, why not a mix of these two? why don't we attach the concept of interface
to the entire source package?

debian/interface could be a file in which we describe the interface
implemented by each component (object) of the source package.

$ cat debian/interface
rules: <rules-interface1>, <rules-interface2>, ...
control: <control-interface1>, <control-interface1>, ...
...

ciao,
-- 
Luca - De Whiskey's - De Vitis              | Elegant or ugly code as well
aliases: Luca ^De [A-Z][A-Za-z\-]*[iy]'\?s$ | as fine or rude sentences have
Luca, a wannabe ``Good guy''.               | something in common: they
local LANG="it_IT@euro"                     | don't depend on the language.
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Branden Robinson <branden@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #190 received at 218893@bugs.debian.org (full text, mbox):

From: Branden Robinson <branden@debian.org>
To: Luca - De Whiskey's - De Vitis <luca@debian.org>
Cc: Adam Heath <doogie@debian.org>, 218893@bugs.debian.org
Subject: Re: Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
Date: Thu, 6 Nov 2003 13:31:10 -0500
[Message part 1 (text/plain, inline)]
On Wed, Nov 05, 2003 at 02:35:44PM -0600, Luca - De Whiskey's - De Vitis wrote:
> So, why not a mix of these two? why don't we attach the concept of interface
> to the entire source package?
> 
> debian/interface could be a file in which we describe the interface
> implemented by each component (object) of the source package.
> 
> $ cat debian/interface
> rules: <rules-interface1>, <rules-interface2>, ...
> control: <control-interface1>, <control-interface1>, ...

I don't have a problem with this at all.

-- 
G. Branden Robinson                |       The software said it required
Debian GNU/Linux                   |       Windows 3.1 or better, so I
branden@debian.org                 |       installed Linux.
http://people.debian.org/~branden/ |
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Bill Allombert <allomber@math.u-bordeaux.fr>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #195 received at 218893@bugs.debian.org (full text, mbox):

From: Bill Allombert <allomber@math.u-bordeaux.fr>
To: Branden Robinson <branden@debian.org>, 218893@bugs.debian.org
Subject: Re: Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
Date: Fri, 7 Nov 2003 13:02:56 +0100
On Thu, Nov 06, 2003 at 01:31:10PM -0500, Branden Robinson wrote:
> On Wed, Nov 05, 2003 at 02:35:44PM -0600, Luca - De Whiskey's - De Vitis wrote:
> > So, why not a mix of these two? why don't we attach the concept of interface
> > to the entire source package?
> > 
> > debian/interface could be a file in which we describe the interface
> > implemented by each component (object) of the source package.
> > 
> > $ cat debian/interface
> > rules: <rules-interface1>, <rules-interface2>, ...
> > control: <control-interface1>, <control-interface1>, ...
> 
> I don't have a problem with this at all.

Joy proposed to put such information in debian/control instead.

The idea of a new file was to ease parsing, but since it is read by
dpkg-buildpackage it should be OK.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Josip Rodin <joy@srce.hr>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #200 received at 218893@bugs.debian.org (full text, mbox):

From: Josip Rodin <joy@srce.hr>
To: 218893@bugs.debian.org
Subject: Re: Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
Date: Fri, 7 Nov 2003 14:14:04 +0100
On Fri, Nov 07, 2003 at 01:02:56PM +0100, Bill Allombert wrote:
> > > So, why not a mix of these two? why don't we attach the concept of interface
> > > to the entire source package?
> > > 
> > > debian/interface could be a file in which we describe the interface
> > > implemented by each component (object) of the source package.
> > > 
> > > $ cat debian/interface
> > > rules: <rules-interface1>, <rules-interface2>, ...
> > > control: <control-interface1>, <control-interface1>, ...
> > 
> > I don't have a problem with this at all.
> 
> Joy proposed to put such information in debian/control instead.
> 
> The idea of a new file was to ease parsing, but since it is read by
> dpkg-buildpackage it should be OK.

Yeah. If someone really thinks of changing the control file interface as
well, where's the guarantee that debian/ will be in the same place, and that
debian/interface won't stand out? I think that putting this into the source
section of debian/control is quite appropriate.

-- 
     2. That which causes joy or happiness.



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Luca - De Whiskey's - De Vitis <luca@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #205 received at 218893@bugs.debian.org (full text, mbox):

From: Luca - De Whiskey's - De Vitis <luca@debian.org>
To: Josip Rodin <joy@srce.hr>, 218893@bugs.debian.org
Subject: Re: Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
Date: Fri, 7 Nov 2003 08:41:13 -0600
On Fri, Nov 07, 2003 at 02:14:04PM +0100, Josip Rodin wrote:
> Yeah. If someone really thinks of changing the control file interface as
> well, where's the guarantee that debian/ will be in the same place, and that
> debian/interface won't stand out? I think that putting this into the source
> section of debian/control is quite appropriate.

Yes, but the only thing against putting the n^th tag in debian control is that
it doesn't scale. Should we ever have the same need for files other
than rules, we'll have to include "yet another tag". This also force us to be
stick to control file format, while there is no need. Tags in debian/control are in
no case the same as those used in a debian/interface: you'll never need to
express alternatives or version-depends on an interface, leaving it to a
simple list.

To me, adding another tag would mean another patch, not a solution. The point
here is that our sources are becoming more complex each day. We cant go on
with patches for long.

ciao,
-- 
Luca - De Whiskey's - De Vitis              | Elegant or ugly code as well
aliases: Luca ^De [A-Z][A-Za-z\-]*[iy]'\?s$ | as fine or rude sentences have
Luca, a wannabe ``Good guy''.               | something in common: they
local LANG="it_IT@euro"                     | don't depend on the language.



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Luca - De Whiskey's - De Vitis <luca@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #210 received at 218893@bugs.debian.org (full text, mbox):

From: Luca - De Whiskey's - De Vitis <luca@debian.org>
To: Josip Rodin <joy@srce.hr>, 218893@bugs.debian.org
Subject: Re: Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
Date: Fri, 7 Nov 2003 13:25:37 -0600
On Fri, Nov 07, 2003 at 02:14:04PM +0100, Josip Rodin wrote:
> Yeah. If someone really thinks of changing the control file interface as
> well, where's the guarantee that debian/ will be in the same place, and that
> debian/interface won't stand out? I think that putting this into the source
> section of debian/control is quite appropriate.

Oh, BTW, debian/interface implyes debian/ exists. debian/control has always
been a required file and debian/interface does not aim to replace or overlap
with it. I don't think it would be more complicated than haveing a new tag in
debian/control, implementing debian/rules.version or any other proposal.
-- 
Luca - De Whiskey's - De Vitis              | Elegant or ugly code as well
aliases: Luca ^De [A-Z][A-Za-z\-]*[iy]'\?s$ | as fine or rude sentences have
Luca, a wannabe ``Good guy''.               | something in common: they
local LANG="it_IT@euro"                     | don't depend on the language.



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Josip Rodin <joy@srce.hr>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #215 received at 218893@bugs.debian.org (full text, mbox):

From: Josip Rodin <joy@srce.hr>
To: 218893@bugs.debian.org
Subject: Re: Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
Date: Sat, 8 Nov 2003 01:19:55 +0100
On Fri, Nov 07, 2003 at 08:41:13AM -0600, Luca - De Whiskey's - De Vitis wrote:
> > Yeah. If someone really thinks of changing the control file interface as
> > well, where's the guarantee that debian/ will be in the same place, and
> > that debian/interface won't stand out? I think that putting this into
> > the source section of debian/control is quite appropriate.
> 
> Yes, but the only thing against putting the n^th tag in debian control is that
> it doesn't scale. Should we ever have the same need for files other
> than rules, we'll have to include "yet another tag".

As opposed to putting all that into debian/whathaveyou? I fail to see how
this makes any difference.

-- 
     2. That which causes joy or happiness.



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Josip Rodin <joy@srce.hr>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #220 received at 218893@bugs.debian.org (full text, mbox):

From: Josip Rodin <joy@srce.hr>
To: 218893@bugs.debian.org
Subject: Re: Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
Date: Sat, 8 Nov 2003 01:24:45 +0100
On Fri, Nov 07, 2003 at 01:25:37PM -0600, Luca - De Whiskey's - De Vitis wrote:
> > Yeah. If someone really thinks of changing the control file interface as
> > well, where's the guarantee that debian/ will be in the same place, and
> > that debian/interface won't stand out? I think that putting this into
> > the source section of debian/control is quite appropriate.
> 
> Oh, BTW, debian/interface implyes debian/ exists. debian/control has
> always been a required file and debian/interface does not aim to replace
> or overlap with it.

The point I was trying to make is that if debian/control is not to be used,
then there must be a reason for that. The reason for that would presumably
be that debian/control may not be what/where it is now in some later
incarnation of source packages. And if debian/control went somewhere else,
then there's no reason why debian/ wouldn't go somewhere else as well.
Thus making debian/interface just as volatile, except that there's two files
to worry about (control and interface) rather than just one.

(FWIW, I've seen doogie mention thinking of moving debian/ to dpkg/ at some
point.)

-- 
     2. That which causes joy or happiness.



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Branden Robinson <branden@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #225 received at 218893@bugs.debian.org (full text, mbox):

From: Branden Robinson <branden@debian.org>
To: Bill Allombert <allomber@math.u-bordeaux.fr>
Cc: 218893@bugs.debian.org
Subject: Re: Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
Date: Fri, 7 Nov 2003 22:42:46 -0500
[Message part 1 (text/plain, inline)]
On Fri, Nov 07, 2003 at 01:02:56PM +0100, Bill Allombert wrote:
> Joy proposed to put such information in debian/control instead.
> 
> The idea of a new file was to ease parsing, but since it is read by
> dpkg-buildpackage it should be OK.

This prevents people from using tricks like debian/control.in.

debian/rules.in is almost impossible, but debian/control can be
generated by debian/rules.

Also, having to parse debian/control to determine what format
debian/control might be in is a bad idea.

-- 
G. Branden Robinson                |       Convictions are more dangerous
Debian GNU/Linux                   |       enemies of truth than lies.
branden@debian.org                 |       -- Friedrich Nietzsche
http://people.debian.org/~branden/ |
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Luca - De Whiskey's - De Vitis <luca@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #230 received at 218893@bugs.debian.org (full text, mbox):

From: Luca - De Whiskey's - De Vitis <luca@debian.org>
To: Josip Rodin <joy@srce.hr>, 218893@bugs.debian.org
Subject: Re: Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
Date: Sat, 8 Nov 2003 03:42:49 -0600
On Sat, Nov 08, 2003 at 01:19:55AM +0100, Josip Rodin wrote:
> As opposed to putting all that into debian/whathaveyou? I fail to see how
> this makes any difference.

I've not proposed to "put all that in debian/whathaveyou". I've proposed to
put the interface offered/needed by required (end eventually other) components
of debian/ not in a file that might be, it self, one of those components.
As Branden already pointed out your might be a bad idea.

If you put a tag you'll patch the problem, show restricted prospecitves, and
add more burden to the same component, while we need a more complex structure,
flatten the resonsibilities of each component and eventually create new one.
Small, fast and agile components with one precise objective.

Moreover, people might need to automatically generate control file at build
time (i had to), and heveing to generate it with the clean target of
debian/rules is dirty trick and is not in the meaning of the target.

ciao,
-- 
Luca - De Whiskey's - De Vitis              | Elegant or ugly code as well
aliases: Luca ^De [A-Z][A-Za-z\-]*[iy]'\?s$ | as fine or rude sentences have
Luca, a wannabe ``Good guy''.               | something in common: they
local LANG="it_IT@euro"                     | don't depend on the language.



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Josip Rodin <joy@srce.hr>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #235 received at 218893@bugs.debian.org (full text, mbox):

From: Josip Rodin <joy@srce.hr>
To: 218893@bugs.debian.org
Subject: Re: Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
Date: Sat, 8 Nov 2003 14:39:40 +0100
On Fri, Nov 07, 2003 at 10:42:46PM -0500, Branden Robinson wrote:
> > Joy proposed to put such information in debian/control instead.
> > 
> > The idea of a new file was to ease parsing, but since it is read by
> > dpkg-buildpackage it should be OK.
> 
> This prevents people from using tricks like debian/control.in.

Once again, it doesn't, because this would be in the source section, not the
binary section(s). The source section is inherently immutable, or at least I
don't see how anyone would expect it not to be and at the same time expect
other things like debian/control or debian/ existing.

> Also, having to parse debian/control to determine what format
> debian/control might be in is a bad idea.

The idea of having a generic interface file, while worth contemplating,
is going one layer too high in generalizing WRT the problem at hand.

-- 
     2. That which causes joy or happiness.



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Josip Rodin <joy@srce.hr>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #240 received at 218893@bugs.debian.org (full text, mbox):

From: Josip Rodin <joy@srce.hr>
To: 218893@bugs.debian.org
Subject: Re: Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
Date: Sat, 8 Nov 2003 14:47:38 +0100
On Sat, Nov 08, 2003 at 03:42:49AM -0600, Luca - De Whiskey's - De Vitis wrote:
> If you put a tag you'll patch the problem, show restricted prospecitves,
> and add more burden to the same component, while we need a more complex
> structure, flatten the resonsibilities of each component and eventually
> create new one. Small, fast and agile components with one precise
> objective.

Again, I don't see where all that's going. If you want to go as far as not
expecting debian/control to include some essential things, why wouldn't you
want to go as far as not expecting debian/ to include those things as well?

Either we work within the existing environment, or we extend the environment
to support all the extra things that people envision they will need.
Extending it partially, without foreseeing further development, doesn't seem
to me like something we should bother with.

(I've answered the question about autogenerated control files two times
already, I'm getting tired of repeating it. :)

-- 
     2. That which causes joy or happiness.



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Adam Heath <doogie@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #245 received at 218893@bugs.debian.org (full text, mbox):

From: Adam Heath <doogie@debian.org>
To: Josip Rodin <joy@srce.hr>, <218893@bugs.debian.org>
Subject: Re: Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
Date: Sat, 8 Nov 2003 18:23:26 -0600 (CST)
On Sat, 8 Nov 2003, Josip Rodin wrote:

> (FWIW, I've seen doogie mention thinking of moving debian/ to dpkg/ at some
> point.)

I don't recall this.  However, I could see mv debian deb.




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Adam Heath <doogie@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #250 received at 218893@bugs.debian.org (full text, mbox):

From: Adam Heath <doogie@debian.org>
To: Branden Robinson <branden@debian.org>, <218893@bugs.debian.org>
Subject: Re: Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
Date: Sat, 8 Nov 2003 18:24:09 -0600 (CST)
On Fri, 7 Nov 2003, Branden Robinson wrote:

> On Fri, Nov 07, 2003 at 01:02:56PM +0100, Bill Allombert wrote:
> > Joy proposed to put such information in debian/control instead.
> >
> > The idea of a new file was to ease parsing, but since it is read by
> > dpkg-buildpackage it should be OK.
>
> This prevents people from using tricks like debian/control.in.

debian/control *must* exist when the source package is unpacked.  Period.

Whether it is overwritten later, is a separate matter.




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Branden Robinson <branden@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #255 received at 218893@bugs.debian.org (full text, mbox):

From: Branden Robinson <branden@debian.org>
To: 218893@bugs.debian.org
Subject: Re: Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
Date: Mon, 10 Nov 2003 00:34:53 -0500
[Message part 1 (text/plain, inline)]
On Sat, Nov 08, 2003 at 06:24:09PM -0600, Adam Heath wrote:
> On Fri, 7 Nov 2003, Branden Robinson wrote:
> 
> > On Fri, Nov 07, 2003 at 01:02:56PM +0100, Bill Allombert wrote:
> > > Joy proposed to put such information in debian/control instead.
> > >
> > > The idea of a new file was to ease parsing, but since it is read by
> > > dpkg-buildpackage it should be OK.
> >
> > This prevents people from using tricks like debian/control.in.
> 
> debian/control *must* exist when the source package is unpacked.  Period.
> 
> Whether it is overwritten later, is a separate matter.

Uh, what if I want to put the following at the very top of my
debian/control file?

# $Id$

I was given to understand that dpkg 1.10.15 or so would be just fine
with it, whereas dpkg 1.9.21 or so would vomit all over it.

-- 
G. Branden Robinson                |     There's something wrong if you're
Debian GNU/Linux                   |     always right.
branden@debian.org                 |     -- Glasow's Law
http://people.debian.org/~branden/ |
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Adam Heath <doogie@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #260 received at 218893@bugs.debian.org (full text, mbox):

From: Adam Heath <doogie@debian.org>
To: Branden Robinson <branden@debian.org>, <218893@bugs.debian.org>
Subject: Re: Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
Date: Mon, 10 Nov 2003 11:26:24 -0600 (CST)
On Mon, 10 Nov 2003, Branden Robinson wrote:

> Uh, what if I want to put the following at the very top of my
> debian/control file?
>
> # $Id$
>
> I was given to understand that dpkg 1.10.15 or so would be just fine
> with it, whereas dpkg 1.9.21 or so would vomit all over it.

Placing comments in the leading paragraph may cause problems with older
versions.

However, for buildds, the build-depends will already be installed by the time
your package is unpacked, so in practice, I doubt this is of much concern.





Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Branden Robinson <branden@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #265 received at 218893@bugs.debian.org (full text, mbox):

From: Branden Robinson <branden@debian.org>
To: 218893@bugs.debian.org
Subject: Re: Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
Date: Tue, 11 Nov 2003 19:07:42 -0500
[Message part 1 (text/plain, inline)]
On Mon, Nov 10, 2003 at 11:26:24AM -0600, Adam Heath wrote:
> On Mon, 10 Nov 2003, Branden Robinson wrote:
> 
> > Uh, what if I want to put the following at the very top of my
> > debian/control file?
> >
> > # $Id$
> >
> > I was given to understand that dpkg 1.10.15 or so would be just fine
> > with it, whereas dpkg 1.9.21 or so would vomit all over it.
> 
> Placing comments in the leading paragraph may cause problems with older
> versions.
> 
> However, for buildds, the build-depends will already be installed by the time
> your package is unpacked, so in practice, I doubt this is of much concern.

Is there a reason we need to preserve the (presumably existing)
requirement that debian/control exist in the .tar.gz or diff.gz?

What is debian/control used for during package unpack?

-- 
G. Branden Robinson                |     If God had intended for man to go
Debian GNU/Linux                   |     about naked, we would have been
branden@debian.org                 |     born that way.
http://people.debian.org/~branden/ |
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Bill Allombert <allomber@math.u-bordeaux.fr>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #270 received at 218893@bugs.debian.org (full text, mbox):

From: Bill Allombert <allomber@math.u-bordeaux.fr>
To: 218893@bugs.debian.org
Subject: Re: Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
Date: Wed, 12 Nov 2003 21:35:46 +0100
Hello,

I am offering a third patch that implement the Build-Options control
field proposal.

--- policy.sgml	Wed Oct 29 22:49:42 2003
+++ policy.sgml.new3	Wed Nov 12 21:25:12 2003
@@ -1856,15 +1856,6 @@
 	      </p>
 
 	      <p>
-		If one or both of the targets <tt>build-arch</tt> and
-		<tt>build-indep</tt> are not provided, then invoking
-		<file>debian/rules</file> with one of the not-provided
-		targets as arguments should produce a exit status code
-		of 2.  Usually this is provided automatically by make
-		if the target is missing.
-	      </p>
-
-	      <p>
 		The <tt>build-arch</tt> and <tt>build-indep</tt> targets
 		must not do anything that might require root privilege.
 	      </p>
@@ -2209,6 +2200,7 @@
 	    <item><qref id="f-Section"><tt>Section</tt></qref> (recommended)</item>
 	    <item><qref id="f-Priority"><tt>Priority</tt></qref> (recommended)</item>
 	    <item><qref id="sourcebinarydeps"><tt>Build-Depends</tt> et al</qref></item>
+	    <item><qref id="f-Build-Options"><tt>Build-Options</tt></qref> (optional)</item>
 	    <item><qref id="f-Standards-Version"><tt>Standards-Version</tt></qref> (recommended)</item>
 	  </list>
 	</p>
@@ -2575,6 +2567,19 @@
 	  </p>
 
 	</sect1>
+        <sect1 id="f-Build-Options">
+        <heading><tt>Build-Options</tt></heading>
+        <p>
+           The syntax is a list of options separated by
+	   commas that are implemented in the build process. 
+           The following options are defined:
+           <list>
+             <item> <tt>build-arch</tt> The optional targets "build-arch"
+                 and "build-indep" are implemented by <tt>debian/rules</tt>
+                 as defined in <ref id="debianrules">.  </item>
+           </list>
+        </p>
+        </sect1>
 
 	<sect1 id="f-Version">
 	  <heading><tt>Version</tt></heading>

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Luca - De Whiskey's - De Vitis <luca@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #275 received at 218893@bugs.debian.org (full text, mbox):

From: Luca - De Whiskey's - De Vitis <luca@debian.org>
To: Bill Allombert <allomber@math.u-bordeaux.fr>, 218893@bugs.debian.org
Subject: Re: Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
Date: Thu, 13 Nov 2003 02:25:13 -0600
On Wed, Nov 12, 2003 at 09:35:46PM +0100, Bill Allombert wrote:
> Hello,
> 
> I am offering a third patch that implement the Build-Options control
> field proposal.

I appreciate your efforts, but i'm sorry: i still have not seen a reply to
last mail from Branden:
Message-ID: <20031112000742.GD30281@deadbeast.net>
References: <20031110053453.GU27445@deadbeast.net>

The fact that i'm not writing mails does not imply that i agree: i'm simply
waiting reply to questions i would have asked. Indeed you've at least two
seconds to this proposal, but there are still uncovered issues.

ciao,
-- 
Luca - De Whiskey's - De Vitis              | Elegant or ugly code as well
aliases: Luca ^De [A-Z][A-Za-z\-]*[iy]'\?s$ | as fine or rude sentences have
Luca, a wannabe ``Good guy''.               | something in common: they
local LANG="it_IT@euro"                     | don't depend on the language.



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Adam Heath <doogie@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #280 received at 218893@bugs.debian.org (full text, mbox):

From: Adam Heath <doogie@debian.org>
To: Bill Allombert <allomber@math.u-bordeaux.fr>, <218893@bugs.debian.org>
Subject: Re: Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
Date: Thu, 13 Nov 2003 19:47:03 -0600 (CST)
On Wed, 12 Nov 2003, Bill Allombert wrote:

> Hello,
>
> I am offering a third patch that implement the Build-Options control
> field proposal.

I reject this proposal, until such time as the code has implemented it.

hint: send patches to the bts for dpkg-dev





Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Luca - De Whiskey's - De Vitis <luca@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #285 received at 218893@bugs.debian.org (full text, mbox):

From: Luca - De Whiskey's - De Vitis <luca@debian.org>
To: Adam Heath <doogie@debian.org>, 218893@bugs.debian.org
Subject: Re: Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
Date: Fri, 14 Nov 2003 04:01:25 -0600
On Thu, Nov 13, 2003 at 07:47:03PM -0600, Adam Heath wrote:
> > I am offering a third patch that implement the Build-Options control
> > field proposal.
> 
> I reject this proposal, until such time as the code has implemented it.
> 
> hint: send patches to the bts for dpkg-dev

So you are going to implement this even if the discussion is not already
closed. Of course you can implement it anyway, but it's unfair to ignore what
Branden Robinson asked:

Message-ID: <20031112000742.GD30281@deadbeast.net>
References: <20031110053453.GU27445@deadbeast.net>

Which is also of interest to me. You might have privately replyed, but in this
case i'd like the answare to be sent here for logging too.

thanks,
-- 
Luca - De Whiskey's - De Vitis              | Elegant or ugly code as well
aliases: Luca ^De [A-Z][A-Za-z\-]*[iy]'\?s$ | as fine or rude sentences have
Luca, a wannabe ``Good guy''.               | something in common: they
local LANG="it_IT@euro"                     | don't depend on the language.



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Julian Gilbey <jdg@polya.uklinux.net>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #290 received at 218893@bugs.debian.org (full text, mbox):

From: Julian Gilbey <jdg@polya.uklinux.net>
To: Luca - De Whiskey's - De Vitis <luca@debian.org>, 218893@bugs.debian.org
Cc: Bill Allombert <allomber@math.u-bordeaux.fr>
Subject: Re: Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
Date: Fri, 14 Nov 2003 12:38:39 +0000
On Thu, Nov 13, 2003 at 02:25:13AM -0600, Luca - De Whiskey's - De Vitis wrote:
> I appreciate your efforts, but i'm sorry: i still have not seen a reply to
> last mail from Branden:
> Message-ID: <20031112000742.GD30281@deadbeast.net>
> References: <20031110053453.GU27445@deadbeast.net>

Please could you provide references in the form of
http://lists.debian.org/... so that we can track these down?

Thanks,

   Julian

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

        Julian Gilbey, website: http://www.polya.uklinux.net/
   Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/
     Visit http://www.thehungersite.com/ to help feed the hungry



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Bill Allombert <allomber@math.u-bordeaux.fr>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #295 received at 218893@bugs.debian.org (full text, mbox):

From: Bill Allombert <allomber@math.u-bordeaux.fr>
Cc: Luca - De Whiskey's - De Vitis <luca@debian.org>, 218893@bugs.debian.org
Subject: Re: Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
Date: Fri, 14 Nov 2003 13:49:19 +0100
On Fri, Nov 14, 2003 at 12:38:39PM +0000, Julian Gilbey wrote:
> On Thu, Nov 13, 2003 at 02:25:13AM -0600, Luca - De Whiskey's - De Vitis wrote:
> > I appreciate your efforts, but i'm sorry: i still have not seen a reply to
> > last mail from Branden:
> > Message-ID: <20031112000742.GD30281@deadbeast.net>
> > References: <20031110053453.GU27445@deadbeast.net>
> 
> Please could you provide references in the form of
> http://lists.debian.org/... so that we can track these down?

Here it is:
http://lists.debian.org/debian-policy/2003/debian-policy-200311/msg00092.html

Note that http://lists.debian.org autmomatically add link to messages
matching Message-ID.

However, Branden question belong more to debian-dpkg than here.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Andreas Metzler <ametzler@logic.univie.ac.at>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #300 received at 218893@bugs.debian.org (full text, mbox):

From: Andreas Metzler <ametzler@logic.univie.ac.at>
To: 218893@bugs.debian.org
Subject: Re: Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
Date: Fri, 14 Nov 2003 14:05:11 +0100
On Fri, Nov 14, 2003 at 12:38:39PM +0000, Julian Gilbey wrote:
> On Thu, Nov 13, 2003 at 02:25:13AM -0600, Luca - De Whiskey's - De Vitis wrote:
> > I appreciate your efforts, but i'm sorry: i still have not seen a reply to
> > last mail from Branden:
> > Message-ID: <20031112000742.GD30281@deadbeast.net>

http://lists.debian.org/debian-policy/2003/debian-policy-200311/msg00092.html

> > References: <20031110053453.GU27445@deadbeast.net>

http://lists.debian.org/debian-policy/2003/debian-policy-200311/msg00085.html

> Please could you provide references in the form of
> http://lists.debian.org/... so that we can track these down?

hth, cu andreas



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Julian Gilbey <jdg@polya.uklinux.net>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #305 received at 218893@bugs.debian.org (full text, mbox):

From: Julian Gilbey <jdg@polya.uklinux.net>
To: Bill Allombert <allomber@math.u-bordeaux.fr>, 218893@bugs.debian.org
Cc: debian-policy@lists.debian.org, Luca - De Whiskey's - De Vitis <luca@debian.org>
Subject: Re: Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
Date: Fri, 14 Nov 2003 13:54:51 +0000
On Fri, Nov 14, 2003 at 01:49:19PM +0100, Bill Allombert wrote:
> > > I appreciate your efforts, but i'm sorry: i still have not seen a reply to
> > > last mail from Branden:
> > > Message-ID: <20031112000742.GD30281@deadbeast.net>
> > > References: <20031110053453.GU27445@deadbeast.net>
> > 
> > Please could you provide references in the form of
> > http://lists.debian.org/... so that we can track these down?
> 
> Here it is:
> http://lists.debian.org/debian-policy/2003/debian-policy-200311/msg00092.html
> 
> Note that http://lists.debian.org autmomatically add link to messages
> matching Message-ID.

How?  I haven't figured out how to search by Message-ID.

> However, Branden question belong more to debian-dpkg than here.

In response to Branden's question (does debian/control already have to
exist when the package is unpacked), I would suggest the following:

Before debian/rules build* is run, one has to check the
build-dependencies.  So at this point, at least the source section of
debian/control must exist.  And since this field (whatever form it
eventually takes) would exist in the source section of debian/control,
and would not be needed until after the build-dependencies are
checked, there should be no problem.

And then again, we can always use debian/interfaces or
debian/rules.targets or something similar instead....

   Julian

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

        Julian Gilbey, website: http://www.polya.uklinux.net/
   Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/
     Visit http://www.thehungersite.com/ to help feed the hungry



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Wichert Akkerman <wichert@wiggy.net>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #310 received at 218893@bugs.debian.org (full text, mbox):

From: Wichert Akkerman <wichert@wiggy.net>
To: Adam Heath <doogie@debian.org>, 218893@bugs.debian.org
Subject: Re: Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
Date: Fri, 14 Nov 2003 23:15:14 +0100
Previously Adam Heath wrote:
> On Sat, 8 Nov 2003, Josip Rodin wrote:
> > (FWIW, I've seen doogie mention thinking of moving debian/ to dpkg/ at some
> > point.)
> 
> I don't recall this.  However, I could see mv debian deb.

I said that.

Wichert.

-- 
Wichert Akkerman <wichert@wiggy.net>    It is simple to make things.
http://www.wiggy.net/                   It is hard to make things simple.




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Branden Robinson <branden@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #315 received at 218893@bugs.debian.org (full text, mbox):

From: Branden Robinson <branden@debian.org>
To: 218893@bugs.debian.org
Subject: Re: Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
Date: Sat, 15 Nov 2003 01:36:16 -0500
[Message part 1 (text/plain, inline)]
On Fri, Nov 14, 2003 at 04:01:25AM -0600, Luca - De Whiskey's - De Vitis wrote:
> So you are going to implement this even if the discussion is not already
> closed. Of course you can implement it anyway, but it's unfair to ignore what
> Branden Robinson asked:
> 
> Message-ID: <20031112000742.GD30281@deadbeast.net>
> References: <20031110053453.GU27445@deadbeast.net>
> 
> Which is also of interest to me. You might have privately replyed, but in this
> case i'd like the answare to be sent here for logging too.

*I* haven't gotten any private replies from Adam about this.

None that weren't duplicates of mails to the -policy list, anyway.
Grumble, grumble.

-- 
G. Branden Robinson                |          You live and learn.
Debian GNU/Linux                   |          Or you don't live long.
branden@debian.org                 |          -- Robert Heinlein
http://people.debian.org/~branden/ |
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Bill Allombert <allomber@math.u-bordeaux.fr>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #320 received at 218893@bugs.debian.org (full text, mbox):

From: Bill Allombert <allomber@math.u-bordeaux.fr>
To: Adam Heath <doogie@debian.org>
Cc: 218893@bugs.debian.org
Subject: Re: Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
Date: Mon, 17 Nov 2003 19:01:38 +0100
[Message part 1 (text/plain, inline)]
On Thu, Nov 13, 2003 at 07:47:03PM -0600, Adam Heath wrote:
> On Wed, 12 Nov 2003, Bill Allombert wrote:
> 
> > Hello,
> >
> > I am offering a third patch that implement the Build-Options control
> > field proposal.
> 
> I reject this proposal, until such time as the code has implemented it.
> 
> hint: send patches to the bts for dpkg-dev

Well, here a patch that implement 
Build-Options: build-arch
as described in the patch #3 I sent here.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 
[patch.3.0 (text/plain, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Adam Heath <doogie@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #325 received at 218893@bugs.debian.org (full text, mbox):

From: Adam Heath <doogie@debian.org>
To: Luca - De Whiskey's - De Vitis <luca@debian.org>, <218893@bugs.debian.org>
Subject: Re: Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
Date: Mon, 17 Nov 2003 13:32:21 -0600 (CST)
On Fri, 14 Nov 2003, Luca - De Whiskey's - De Vitis wrote:

> On Thu, Nov 13, 2003 at 07:47:03PM -0600, Adam Heath wrote:
> > > I am offering a third patch that implement the Build-Options control
> > > field proposal.
> >
> > I reject this proposal, until such time as the code has implemented it.
> >
> > hint: send patches to the bts for dpkg-dev
>
> So you are going to implement this even if the discussion is not already
> closed. Of course you can implement it anyway, but it's unfair to ignore what
> Branden Robinson asked:
>
> Message-ID: <20031112000742.GD30281@deadbeast.net>
> References: <20031110053453.GU27445@deadbeast.net>
>
> Which is also of interest to me. You might have privately replyed, but in this
> case i'd like the answare to be sent here for logging too.

I only reject the proposal, because the changes need to be implemented
*first*, and tested, before policy tries to ram it down our throats.

Policy already tried this once(in this exact case), and we have shown that it
was not implementable.  I don't want a repeat of that.




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Bill Allombert <allomber@math.u-bordeaux.fr>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #330 received at 218893@bugs.debian.org (full text, mbox):

From: Bill Allombert <allomber@math.u-bordeaux.fr>
To: 218893@bugs.debian.org
Cc: Adam Heath <doogie@debian.org>
Subject: Re: Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
Date: Thu, 18 Dec 2003 01:04:45 +0100
[Message part 1 (text/plain, inline)]
On Mon, Nov 17, 2003 at 07:01:38PM +0100, Bill Allombert wrote:
> On Thu, Nov 13, 2003 at 07:47:03PM -0600, Adam Heath wrote:
> > On Wed, 12 Nov 2003, Bill Allombert wrote:
> > 
> > > Hello,
> > >
> > > I am offering a third patch that implement the Build-Options control
> > > field proposal.
> > 
> > I reject this proposal, until such time as the code has implemented it.
> > 
> > hint: send patches to the bts for dpkg-dev
> 
> Well, here a patch that implement 
> Build-Options: build-arch
> as described in the patch #3 I sent here.

Hello Debian-policy, 
Since one month has passed without negative comments, I plan to submit
this patch to dpkg as is.

Cheers,
Bill.
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Andreas Metzler <ametzler@downhill.at.eu.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #335 received at 218893@bugs.debian.org (full text, mbox):

From: Andreas Metzler <ametzler@downhill.at.eu.org>
To: 218893@bugs.debian.org
Cc: Scott James Remnant <scott@netsplit.com>
Subject: Autodetecting existence of build-arch target
Date: Wed, 5 May 2004 11:46:20 +0200
Hello,
I have recently asked Scott James Remnant[1] on IRC for comments on this
problem and the proposed solution (#229357), to add Build-Options:
build-arch' to debian/control if the package supported this target.

I gathered that he was not in favour of it and prompted for alternate
solutions he suggested

make -f debian/rules -pn | grep '^binary-arch:'

This is different to the solution dpkg-buildpackage tried and dropped
some time ago:

| dpkg (1.10.15) unstable; urgency=low
[...]
|   * Back out debian/rules build-arch detection.  It is *not* possible *at
|     all* to detect available targets in a rules file.  Period.
[...]
| dpkg (1.10.11) unstable; urgency=low
[...]
|   * Patch dpkg-buildpackage to call debian/rules -qn build-arch, and if
|     it's available, modify -B handling appropriately.  If build-arch is not
|     available, then when -B was called, do *not* pass -B on to
|     dpkg-checkbuilddeps.  Closes: #203097

Of course all the examples I tried work with both variants. debian-dpkg
does not yield any reference to example that failed during the short
interval build-arch detection was tried.
               cu andreas
[1] cced to make sure I do not misrepresent him.
-- 
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Wouter Verhelst <wouter@grep.be>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #340 received at 218893@bugs.debian.org (full text, mbox):

From: Wouter Verhelst <wouter@grep.be>
To: Andreas Metzler <ametzler@downhill.at.eu.org>, 218893@bugs.debian.org
Cc: Scott James Remnant <scott@netsplit.com>
Subject: Re: Bug#218893: Autodetecting existence of build-arch target
Date: Wed, 5 May 2004 12:23:27 +0200
[Message part 1 (text/plain, inline)]
On Wed, May 05, 2004 at 11:46:20AM +0200, Andreas Metzler wrote:
> Hello,
> I have recently asked Scott James Remnant[1] on IRC for comments on this
> problem and the proposed solution (#229357), to add Build-Options:
> build-arch' to debian/control if the package supported this target.

I've been wondering... why bother? Why can't we just make build-arch and
build-indep mandatory, and make stuff such as

build-indep: build-stamp
build-arch: build-stamp
build: build-stamp
build-stamp: 
	[whatever is necessary]
	touch build-stamp

legal if splitting out build-indep and/or build-arch is impossible or
infeasible? That way, dpkg-buildpackage could assume that all three
targets are available, and just run the build-arch, build-indep, or
build targets, as necessary, without any risk for breakage.

Of course, doing so will need a long and painful transition plan, but I
think this would end us up with something not as kludgy as having to add
a field somewhere that would advertise the availability of certain
options.

Comments?

-- 
         EARTH
     smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
         WATER
 -- with thanks to fortune
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Scott James Remnant <scott@netsplit.com>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #345 received at 218893@bugs.debian.org (full text, mbox):

From: Scott James Remnant <scott@netsplit.com>
To: Andreas Metzler <ametzler@downhill.at.eu.org>, 218893@bugs.debian.org
Cc: Wouter Verhelst <wouter@grep.be>
Subject: Re: Bug#218893: Autodetecting existence of build-arch target
Date: Wed, 05 May 2004 16:12:55 +0100
[Message part 1 (text/plain, inline)]
On Wed, 2004-05-05 at 11:46 +0200, Andreas Metzler wrote:

> I have recently asked Scott James Remnant[1] on IRC for comments on this
> problem and the proposed solution (#229357), to add Build-Options:
> build-arch' to debian/control if the package supported this target.
> 
> I gathered that he was not in favour of it and prompted for alternate
> solutions
> 
Yeah; I don't like the idea that you have to declare which particular
implementation you have followed -- that's a kludge and prone to many a
Murphy attack.

We should either fix the implementation (as Wouter suggested) or be
intelligent enough to detect which implementation is in use (as I
suggested).

> Of course all the examples I tried work with both variants. debian-dpkg
> does not yield any reference to example that failed during the short
> interval build-arch detection was tried.
> 
-q checks for "up to dateness" ... the next time you ran the test, it
would fail because build-stamp had been touched and dpkg-buildpackage
would incorrectly run build for you instead.

Scott
-- 
Have you ever, ever felt like this?
Had strange things happen?  Are you going round the twist?
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Bill Allombert <allomber@math.u-bordeaux.fr>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #350 received at 218893@bugs.debian.org (full text, mbox):

From: Bill Allombert <allomber@math.u-bordeaux.fr>
To: Andreas Metzler <ametzler@downhill.at.eu.org>, 218893@bugs.debian.org
Cc: Scott James Remnant <scott@netsplit.com>
Subject: Re: Bug#218893: Autodetecting existence of build-arch target
Date: Wed, 5 May 2004 17:34:10 +0200
On Wed, May 05, 2004 at 11:46:20AM +0200, Andreas Metzler wrote:
> Hello,
> I have recently asked Scott James Remnant[1] on IRC for comments on this
> problem and the proposed solution (#229357), to add Build-Options:
> build-arch' to debian/control if the package supported this target.
> 
> I gathered that he was not in favour of it and prompted for alternate
> solutions he suggested
> 
> make -f debian/rules -pn | grep '^binary-arch:'

I hope you meant

make -f debian/rules -pn | grep '^build-arch:'

since binary-arch is mandated by policy already.

I am not sure make -n (--dry-run) is safe though.
We could imagine make --dry-run to take an large amount of time
or actively modify the environment by use of $(shell   ) construct.

Thea apparent benefit of this technique is that it will not require
packages to be modified to take advantage of it.

But in practice this is not true:
Only packages that currently FTBFS would work unmodified. All others
will need to be modified to resplit Build-Depends-Indep from
Build-Depends before build-arch to be really useful.
And that will not fix buildd either: the implied assumption that
Build-Depends-Indep imply build-arch is not warranted by policy.

I would like to recall we have had a long discussion on debian-policy
about the whole issue.  I proposed 4 solutions and we finally more or
less settled on the Build-Options: build-arch proposal. At least this
option was amenable to Adam Heath. Following his request I wrote a patch
to dpkg-buildpackage.

I am afraid that implementing 'make -f debian/rules -pn' instead will
lead to the same problems we tried carefully to avoid in this
discussion and will finally delay the issue even more.

1) That assume debian/rules is a Makefile and there is a long standing
flamewar on that topic. One of the dpkg maintainer disagree.

2) buildd need to know whether it should install Build-Depends-Indep.
Assuming Build-Depends-Indep split imply build-arch exist is not correct
with current policy.  This mean it must know whether dpkg-buildpackage
will call build or build-arch. A control field is a clean way to do
that.

3) Build-Options scale to others feature we might want to introduce.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Andreas Metzler <ametzler@logic.univie.ac.at>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #355 received at 218893@bugs.debian.org (full text, mbox):

From: Andreas Metzler <ametzler@logic.univie.ac.at>
To: 218893@bugs.debian.org
Subject: Re: Bug#218893: Autodetecting existence of build-arch target
Date: Wed, 5 May 2004 17:51:30 +0200
On Wed, May 05, 2004 at 05:34:10PM +0200, Bill Allombert wrote:
> On Wed, May 05, 2004 at 11:46:20AM +0200, Andreas Metzler wrote:
> > I have recently asked Scott James Remnant[1] on IRC for comments on this
> > problem and the proposed solution (#229357), to add Build-Options:
> > build-arch' to debian/control if the package supported this target.

> > I gathered that he was not in favour of it and prompted for alternate
> > solutions he suggested

> > make -f debian/rules -pn | grep '^binary-arch:'
 
> I hope you meant
 
> make -f debian/rules -pn | grep '^build-arch:'
 
> since binary-arch is mandated by policy already.

Of course.

[...]
> The apparent benefit of this technique is that it will not require
> packages to be modified to take advantage of it.
> 
> But in practice this is not true:
> Only packages that currently FTBFS would work unmodified. All others
> will need to be modified to resplit Build-Depends-Indep from
> Build-Depends before build-arch to be really useful.
> And that will not fix buildd either: the implied assumption that
> Build-Depends-Indep imply build-arch is not warranted by policy.

Policy is simply wrong in this respect, because it does not describe
the implemented behavior.

Just to recap: Afaik this bugreport is not about "Let us change the
buildds to follow policy." This bug is about making _one_ minimal
change:

Provide a way to make dpkg-buildpackage use "debian/rules build-arch" 
if it exists instead of "debian/rules build".

[...] 
> 2) buildd need to know whether it should install Build-Depends-Indep.
> Assuming Build-Depends-Indep split imply build-arch exist is not correct
> with current policy.  This mean it must know whether dpkg-buildpackage
> will call build or build-arch. A control field is a clean way to do
> that.
[...]

I do not understand that. It is easy. If you use "dpkg-buildpackage
-B" binary-indep does not need to be installed, otherwise it does.
             cu andreas



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Wouter Verhelst <wouter@grep.be>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #360 received at 218893@bugs.debian.org (full text, mbox):

From: Wouter Verhelst <wouter@grep.be>
To: Bill Allombert <allomber@math.u-bordeaux.fr>, 218893@bugs.debian.org
Cc: Andreas Metzler <ametzler@downhill.at.eu.org>, Scott James Remnant <scott@netsplit.com>
Subject: Re: Bug#218893: Autodetecting existence of build-arch target
Date: Wed, 5 May 2004 18:17:35 +0200
On Wed, May 05, 2004 at 05:34:10PM +0200, Bill Allombert wrote:
> But in practice this is not true:
> Only packages that currently FTBFS would work unmodified. All others
> will need to be modified to resplit Build-Depends-Indep from
> Build-Depends before build-arch to be really useful.

How's that? Build-Depends is *not* the opposite of Build-Depends-Indep;
put otherwise, there is no such thing as "Build-Depends-Arch";
Build-Depends could hypothetically be renamed to "Build-Depends-Common"
and stay semantically the same thing.

[...]
> 2) buildd need to know whether it should install Build-Depends-Indep.

Not true. Buildd does not install build-depends-indep, and should not
ever; any proposal that would require in buildd to install
build-depends-indep is broken by design.

Indeed, the very reason for build-depends-indep to exist is for buildd
to /avoid/ installing unnecessary build-dependencies, to not waste time
installing stuff which isn't needed anyway.

[...]

-- 
         EARTH
     smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
         WATER
 -- with thanks to fortune



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Bill Allombert <allomber@math.u-bordeaux.fr>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #365 received at 218893@bugs.debian.org (full text, mbox):

From: Bill Allombert <allomber@math.u-bordeaux.fr>
To: Wouter Verhelst <wouter@grep.be>
Cc: 218893@bugs.debian.org, Scott James Remnant <scott@netsplit.com>
Subject: Re: Bug#218893: Autodetecting existence of build-arch target
Date: Wed, 5 May 2004 18:36:28 +0200
On Wed, May 05, 2004 at 06:17:35PM +0200, Wouter Verhelst wrote:
> On Wed, May 05, 2004 at 05:34:10PM +0200, Bill Allombert wrote:
> > But in practice this is not true:
> > Only packages that currently FTBFS would work unmodified. All others
> > will need to be modified to resplit Build-Depends-Indep from
> > Build-Depends before build-arch to be really useful.
> 
> How's that? Build-Depends is *not* the opposite of Build-Depends-Indep;
> put otherwise, there is no such thing as "Build-Depends-Arch";
> Build-Depends could hypothetically be renamed to "Build-Depends-Common"
> and stay semantically the same thing.
> 
> [...]
> > 2) buildd need to know whether it should install Build-Depends-Indep.
> 
> Not true. Buildd does not install build-depends-indep, and should not
> ever; any proposal that would require in buildd to install
> build-depends-indep is broken by design.

So you posit that any package with a Build-Depends-Indep field and 
no buid-arch target is broken ? In this case please submit a proposal
to amend policy accordingly.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Wouter Verhelst <wouter@grep.be>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #370 received at 218893@bugs.debian.org (full text, mbox):

From: Wouter Verhelst <wouter@grep.be>
To: Bill Allombert <allomber@math.u-bordeaux.fr>
Cc: 218893@bugs.debian.org, Scott James Remnant <scott@netsplit.com>
Subject: Re: Bug#218893: Autodetecting existence of build-arch target
Date: Wed, 5 May 2004 18:55:50 +0200
On Wed, May 05, 2004 at 06:36:28PM +0200, Bill Allombert wrote:
> So you posit that any package with a Build-Depends-Indep field and 
> no buid-arch target is broken ?

No. Having build-depends-indep implies one of binary-indep, build-indep,
or something similar. It does not say anything, *at all* about the -arch
variants.

(I don't think that build-foo without binary-foo, or bar-arch without
bar-indep is illegal by policy currently, but I'd be happy to be
corrected if I'm wrong)

-- 
         EARTH
     smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
         WATER
 -- with thanks to fortune



Severity set to `wishlist'. Request was from Manoj Srivastava <srivasta@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Manoj Srivastava <srivasta@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #377 received at 218893@bugs.debian.org (full text, mbox):

From: Manoj Srivastava <srivasta@debian.org>
To: debian-policy@lists.debian.org
Cc: 218893@bugs.debian.org
Subject: Re: Bug#218893: Autodetecting existence of build-arch target
Date: Mon, 23 Aug 2004 16:12:45 -0500
On Wed, 5 May 2004 17:34:10 +0200, Bill Allombert <allomber@math.u-bordeaux.fr> said: 

> I am afraid that implementing 'make -f debian/rules -pn' instead
> will lead to the same problems we tried carefully to avoid in this
> discussion and will finally delay the issue even more.

> 1) That assume debian/rules is a Makefile and there is a long
>    standing flamewar on that topic. One of the dpkg maintainer disagree.

	Policy already mandates that ./debian.rules is a Makefile, and
 this is one of the reasons for it: when the rules file is so defined,
 we can do things like ./debian/rules -np | grep ....

	manoj
-- 
The economy depends about as much on economists as the weather does on
weather forecasters. Jean-Paul Kauffmann
Manoj Srivastava   <srivasta@debian.org>  <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Wouter Verhelst <wouter@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #382 received at 218893@bugs.debian.org (full text, mbox):

From: Wouter Verhelst <wouter@debian.org>
To: 218893@bugs.debian.org
Subject: Kicking this back to life
Date: Tue, 23 May 2006 22:17:01 +0200
[Message part 1 (text/plain, inline)]
Hi,

The last post to this bug was done on 2004-08-23, which is ages ago. I
think it's safe to say that Bill's proposal (create
debian/rules.{version,targets} files which define what interfaces are
implemented by the debian/rules file) did not get enough seconds.
Personally, I happen to think that such a file would not be a very clean
solution, which is the main reason why I didn't second it; Scott James
Remnant, then the dpkg maintainer (dunno whether he still is), also
hinted something to the same effect.

So, instead, I'm going to propose a patch to which I already hinted in
<20040505102327.GA5013@grep.be>: make build-arch and build-indep
mandatory (in the long term), but make it legal for them to depend on
the build target if splitting out their functionality is infeasible or
impossible.

I'm looking for seconds.

Patch follows:

--- policy.sgml.orig	2006-05-23 21:52:54.000000000 +0200
+++ policy.sgml	2006-05-23 22:16:29.000000000 +0200
@@ -1802,14 +1802,15 @@
 	      </p>
 
 	      <p>
-		If one or both of the targets <tt>build-arch</tt> and
-		<tt>build-indep</tt> are not provided, then invoking
-		<file>debian/rules</file> with one of the not-provided
-		targets as arguments should produce a exit status code
-		of 2.  Usually this is provided automatically by make
-		if the target is missing.
-	      </p>
-
+                If it is not technically possible or feasible to provide a
+                <tt>build-arch</tt> or <tt>build-indep</tt> target which
+                compiles <em>only</em> that which is specified above, then
+                you may make these two targets functionally the same as the
+                <tt>build</tt> target, for example by declaring the
+                <tt>build</tt> target a as a make dependency of both the
+                <tt>build-arch</tt> and the <tt>build-indep</tt> targets.
+              </p>
+              
 	      <p>
 		The <tt>build-arch</tt> and <tt>build-indep</tt> targets
 		must not do anything that might require root privilege.

-- 
Fun will now commence
  -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Bill Allombert <allomber@math.u-bordeaux.fr>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #387 received at 218893@bugs.debian.org (full text, mbox):

From: Bill Allombert <allomber@math.u-bordeaux.fr>
To: Wouter Verhelst <wouter@debian.org>, 218893@bugs.debian.org
Subject: Re: Bug#218893: Kicking this back to life
Date: Tue, 23 May 2006 23:15:14 +0200
Hello Wouter,

First thank for bringing back this issue, however...

On Tue, May 23, 2006 at 10:17:01PM +0200, Wouter Verhelst wrote:
> The last post to this bug was done on 2004-08-23, which is ages ago. I
> think it's safe to say that Bill's proposal (create
> debian/rules.{version,targets} files which define what interfaces are
> implemented by the debian/rules file) did not get enough seconds.

...for the record: the debian/rules.{version,targets} was not the final
proposal. The final proposal was the addition of 'Build-Options' to
debian/control and this proposal was drafted after input from all the
people involved.  This proposal is merely waiting for the dpkg
maintainers to make a decision on bug #229357 rather than shelved.  Some
developers mentionned their willingness to second it.

As for your proposal: at the time of the discussion, the dpkg maintainer 
made it clear it was not an option.

Since there are new dpkg maintainers, I asked them on Thu, 19 Jan 2006,
what was their opinion on the matter and whether they would accept my
proposal or yours. So far I did not get any answer.

I consider such answer to be a precondition to any useful subsequent
discussion on this topic.

If they reject my proposal but accept yours but if it require seconds, I
will be happy to second it.

What I don't want is my proposal to be discarded merely because I
proposed it two years ago, and the whole body of discussion wasted.

I have to say I am fighting with this issue since I am a Debian
developer (indeed my very first package triggered the bug) and 
I resent the fact we could not manage to solve it in 5 years as an 
inability of Debian to adress distribution-wide issues.

And please bear with me for taking this bug so personnally.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Wouter Verhelst <wouter@grep.be>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #392 received at 218893@bugs.debian.org (full text, mbox):

From: Wouter Verhelst <wouter@grep.be>
To: Bill Allombert <allomber@math.u-bordeaux.fr>
Cc: 218893@bugs.debian.org
Subject: Re: Bug#218893: Kicking this back to life
Date: Wed, 24 May 2006 00:05:28 +0200
On Tue, May 23, 2006 at 11:15:14PM +0200, Bill Allombert wrote:
> Hello Wouter,
> 
> First thank for bringing back this issue, however...
> 
> On Tue, May 23, 2006 at 10:17:01PM +0200, Wouter Verhelst wrote:
> > The last post to this bug was done on 2004-08-23, which is ages ago. I
> > think it's safe to say that Bill's proposal (create
> > debian/rules.{version,targets} files which define what interfaces are
> > implemented by the debian/rules file) did not get enough seconds.
> 
> ...for the record: the debian/rules.{version,targets} was not the final
> proposal. The final proposal was the addition of 'Build-Options' to
> debian/control and this proposal was drafted after input from all the
> people involved.

Oh? Must've missed that, then.

> This proposal is merely waiting for the dpkg
> maintainers to make a decision on bug #229357 rather than shelved.  Some
> developers mentionned their willingness to second it.
> 
> As for your proposal: at the time of the discussion, the dpkg maintainer 
> made it clear it was not an option.

I disagree (I went through the bug's log before providing the patch); He
made clear that the debian/rules.* stuff was not an option in his eyes,
but I didn't see him mention that making build-{arch,indep} would not be
what he wanted to happen.

Of course, I didn't read every letter of every mail, so I could've
missed it.

> Since there are new dpkg maintainers, I asked them on Thu, 19 Jan 2006,
> what was their opinion on the matter and whether they would accept my
> proposal or yours. So far I did not get any answer.
> 
> I consider such answer to be a precondition to any useful subsequent
> discussion on this topic.

Fair enough.

I proposed this patch because I had not seen any action and therefore
assumed nothing was happening anymore. If that's wrong, so much the
better.

[...]

-- 
Fun will now commence
  -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Bill Allombert <allomber@math.u-bordeaux.fr>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #397 received at 218893@bugs.debian.org (full text, mbox):

From: Bill Allombert <allomber@math.u-bordeaux.fr>
To: Wouter Verhelst <wouter@grep.be>
Cc: 218893@bugs.debian.org
Subject: Re: Bug#218893: Kicking this back to life
Date: Wed, 24 May 2006 00:40:05 +0200
On Wed, May 24, 2006 at 12:05:28AM +0200, Wouter Verhelst wrote:
> On Tue, May 23, 2006 at 11:15:14PM +0200, Bill Allombert wrote:
> > Hello Wouter,
> > This proposal is merely waiting for the dpkg
> > maintainers to make a decision on bug #229357 rather than shelved.  Some
> > developers mentionned their willingness to second it.
> > 
> > As for your proposal: at the time of the discussion, the dpkg maintainer 
> > made it clear it was not an option.
> 
> I disagree (I went through the bug's log before providing the patch); He
> made clear that the debian/rules.* stuff was not an option in his eyes,

The only negative comment from Adam Heath are about the lack of dpkg
patch, but such patch was duly provided.  There is a negative comment
from Scott James Remnant but he was not part of the part of the initial
discussion (he became the dpkg maintainer 6 months after the discusion)
and did not get to the root of the matter.

> but I didn't see him mention that making build-{arch,indep} would not be
> what he wanted to happen.

I agree that this is not documented in the bug log (because it was not
actually proposed there), but doogie was quite vocal about it at the time
on IRC (to the point of /ignore-ing mrvn for merely suggestig the idea).
Anyway the opinion of the current dpkg maintainers is more important.

> > Since there are new dpkg maintainers, I asked them on Thu, 19 Jan 2006,
> > what was their opinion on the matter and whether they would accept my
> > proposal or yours. So far I did not get any answer.
> > 
> > I consider such answer to be a precondition to any useful subsequent
> > discussion on this topic.
> 
> Fair enough.
> 
> I proposed this patch because I had not seen any action and therefore
> assumed nothing was happening anymore. If that's wrong, so much the
> better.

You are not exactly wrong: there is not a lot of evidence we will get
an answer from the new dpkg maintainers any time soon. Maybe you could 
ping the bug #229357, you might have more success than I did.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #402 received at 218893@bugs.debian.org (full text, mbox):

From: Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>
To: Bill Allombert <allomber@math.u-bordeaux.fr>
Cc: 218893@bugs.debian.org, Wouter Verhelst <wouter@debian.org>
Subject: Re: Bug#218893: Kicking this back to life
Date: Wed, 24 May 2006 03:48:47 +0200
Bill Allombert <allomber@math.u-bordeaux.fr> writes:

> Hello Wouter,
>
> First thank for bringing back this issue, however...
>
> On Tue, May 23, 2006 at 10:17:01PM +0200, Wouter Verhelst wrote:
>> The last post to this bug was done on 2004-08-23, which is ages ago. I
>> think it's safe to say that Bill's proposal (create
>> debian/rules.{version,targets} files which define what interfaces are
>> implemented by the debian/rules file) did not get enough seconds.
>
> ...for the record: the debian/rules.{version,targets} was not the final
> proposal. The final proposal was the addition of 'Build-Options' to
> debian/control and this proposal was drafted after input from all the
> people involved.  This proposal is merely waiting for the dpkg
> maintainers to make a decision on bug #229357 rather than shelved.  Some
> developers mentionned their willingness to second it.

I still think that adding an extra header is unneccessary. We already
have the standards version in the control file. The next standards
version could require the build-arch/indep targets to be present and
dpkg-buildpackage could test for the version.

This would, going by the letter, make existing packages in debian
buggy. BUT it would not make any package suddenly unbuildable and we
could easily enough restraing ourself from needlessly reporting this
as a bug till after etch.

For those who claim that requiring build-arch/indep tragets would
waste space in debian/rules a simple "build%:" target, meaning an
increase of 1 char, will do.

MfG
        Goswin

PS: Has anyone counted how many sources don't have build-arch?



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Christian Perrier <bubulle@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #407 received at 218893@bugs.debian.org (full text, mbox):

From: Christian Perrier <bubulle@debian.org>
To: Bill Allombert <allomber@math.u-bordeaux.fr>, 218893@bugs.debian.org
Cc: Wouter Verhelst <wouter@debian.org>
Subject: Re: Bug#218893: Kicking this back to life
Date: Wed, 24 May 2006 06:37:53 +0200
[Message part 1 (text/plain, inline)]
> Since there are new dpkg maintainers, I asked them on Thu, 19 Jan 2006,
> what was their opinion on the matter and whether they would accept my
> proposal or yours. So far I did not get any answer.


You probably sent the request a little bit too early. The dpkg
maintenance team was still in the process of settnf itself up. It is
still, btw, but you might get better chances now.


[signature.asc (application/pgp-signature, inline)]

Changed Bug title to `add Build-Options as a debian/control field' from `Proposal: debian/rules.version file [Fix for the build-arch problem]'. Request was from Russ Allbery <rra@debian.org> to control@bugs.debian.org. (Thu, 05 Jul 2007 00:24:04 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Loïc Minier <lool@dooz.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #414 received at 218893@bugs.debian.org (full text, mbox):

From: Loïc Minier <lool@dooz.org>
To: 218893@bugs.debian.org
Subject: Build-Options and build-arch, noopt, nostrip, ...
Date: Thu, 16 Aug 2007 15:07:04 +0200
        Hi,

 There are many requests to:
 - gradually add support for "build-arch" targets in packages
 - gradually require "nostrip" or "noopt" in DEB_BUILD_OPTIONS
 - add various new fields to DEB_BUILD_OPTIONS

 I like the proposed Build-Options approach to document what a package
 supports or not, but I don't like the fact that packages would be
 required to list an always longer list of flags when these are required
 by policy.

 I propose:
1) to allow the Build-Options field in source packages to document that
   a package supports these comma-separated build-options
2) to document the Build-Options a package MUST and SHOULD implement in
   the current policy version
3) to allow the special "standard" keyword in Build-Options to mean "any
   option required by the policy version in Standards-Version"
4) to document that the absence of a Build-Options field means
   "Build-Options: standard"
5) to document the following Build-Options:
   * nostrip: meaning the package wont strip binaries which can be built
     with debug symbols from the resulting packages
   * noopt: meaning the package will be built with all optimizations
     turned off
   * build-arch: meaning the debian/rules supports the build-arch targe
     to only build arch any packages


 This differs from the original proposal in that it wont require
 packages implementing all required options to have a possibly long
 Build-Options field over the years.  It also explicitely permits
 requiring support for some build-options and recommending support for
 some other based on the standards-version.


 It would be nice if policy could back up support for Build-Options so
 that we can add the field to source packages and start producing some
 metrics of "number of packages supporting option foo" to propose
 release goals or to update the standard requirements in policy.

-- 
Loïc Minier



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #419 received at 218893@bugs.debian.org (full text, mbox):

From: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>
To: Loïc Minier <lool@dooz.org>, 218893@bugs.debian.org
Subject: Re: Bug#218893: Build-Options and build-arch, noopt, nostrip, ...
Date: Fri, 17 Aug 2007 11:35:34 +0200
On Thu, Aug 16, 2007 at 03:07:04PM +0200, Loïc Minier wrote:
>         Hi,
> 
>  There are many requests to:
>  - gradually add support for "build-arch" targets in packages
>  - gradually require "nostrip" or "noopt" in DEB_BUILD_OPTIONS

I am concerned with conflating this two issues which are very different
in nature. DEB_BUILD_OPTIONS require much more flexibility than build-arch.

>  - add various new fields to DEB_BUILD_OPTIONS
> 
>  I like the proposed Build-Options approach to document what a package
>  supports or not, but I don't like the fact that packages would be
>  required to list an always longer list of flags when these are required
>  by policy.
> 
>  I propose:
> 1) to allow the Build-Options field in source packages to document that
>    a package supports these comma-separated build-options
> 2) to document the Build-Options a package MUST and SHOULD implement in
>    the current policy version

That does not really work: you cannot make a lot of packages RC buggy
just by changing the requirement for a Build-Option in a new policy
. So once the meaning of a build-option is decided, it need to stay
essentially fixed.

> 3) to allow the special "standard" keyword in Build-Options to mean "any
>    option required by the policy version in Standards-Version"

This make handling of Build-Options by build scripts too hard in my
opinion. Furthermore, this was essentially opposed in the discussion of
this bug, and I finally proposed Build-Options to address them.

There were concerns that:
1) packaging will become more complex over time by increase in
requirement.
2) the notion that "newer is better" will lead packages to acquire
useless interface just because it is the most recent version of
policy.

Build-Options was really meant to be at the option of the packager,
hence the name Build-Options, and not Build-Standard.
Policy can enforce new interfaces by itself without the use of
Build-Options. 

> 4) to document that the absence of a Build-Options field means
>    "Build-Options: standard"

Then what is the point of "standard" ? To allow package to not implement
a Build-Options by using Build-Options: nostandard ? This seems backward.

> 5) to document the following Build-Options:
>    * nostrip: meaning the package wont strip binaries which can be built
>      with debug symbols from the resulting packages
>    * noopt: meaning the package will be built with all optimizations
>      turned off
>    * build-arch: meaning the debian/rules supports the build-arch targe
>      to only build arch any packages

As I said I do not like to conflate them: build-arch describe the
interface to build binary packages suitable for the main archive
by developers and buildd.

nostrip/noopt describe ways to build debugging packages that should not
be uploaded to the main archive. If the option is not implement, policy
require that the package is build normally.

Maybe what you want is a field Build-Standard.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Loïc Minier <lool@dooz.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #424 received at 218893@bugs.debian.org (full text, mbox):

From: Loïc Minier <lool@dooz.org>
To: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>
Cc: 218893@bugs.debian.org
Subject: Re: Bug#218893: Build-Options and build-arch, noopt, nostrip, ...
Date: Fri, 17 Aug 2007 13:35:47 +0200
On Fri, Aug 17, 2007, Bill Allombert wrote:
> >  There are many requests to:
> >  - gradually add support for "build-arch" targets in packages
> >  - gradually require "nostrip" or "noopt" in DEB_BUILD_OPTIONS
> I am concerned with conflating this two issues which are very different
> in nature. DEB_BUILD_OPTIONS require much more flexibility than build-arch.

 To clarify: this is not about having DEB_BUILD_OPTIONS in a
 Build-Options field, but about declaring which options the build rules
 support, so a simple list of compatibility flags, not a complex syntax.

> > 2) to document the Build-Options a package MUST and SHOULD implement in
> >    the current policy version
> That does not really work: you cannot make a lot of packages RC buggy
> just by changing the requirement for a Build-Option in a new policy
> .

 Exactly like for other policy changes, the requirements would only be
 added if a large number of packages support the option.  But the
 addition of Build-Options helps in two ways:
 - it gives us a metric of the number of packages implementing an option
 - it permits checking whether an option will be supported -- or not,
   even if this option isn't required by policy

 So if you thought I saw Build-Options as a stick to force packages to
 implement new features, I do not; I see it as an interface to help
 packages list their capabilities.

>   So once the meaning of a build-option is decided, it need to stay
> essentially fixed.

 (I didn't understand this part.)

> > 3) to allow the special "standard" keyword in Build-Options to mean "any
> >    option required by the policy version in Standards-Version"
> 
> This make handling of Build-Options by build scripts too hard in my
> opinion. Furthermore, this was essentially opposed in the discussion of
> this bug, and I finally proposed Build-Options to address them.

 I don't think this adds complexity as we can provide a
 dpkg-parseoptions command wrapping the query, just like we have
 dpkg-parsechangelog.  I agree it adds a level of indirection, but it
 would also help keep the Build-Options short if it grows.

> There were concerns that:
> 1) packaging will become more complex over time by increase in
> requirement.

 If we listen to such a complaint, we wont ever add new requirements and
 our packages wont ever do more than what they currently do.

 Debhelper and CDBS are easy examples of wrappers helping in the
 implementation of standard build-options such as nostrip and noopt, I
 think we can improve these and even create new helpers, but because the
 build system is flexible doesn't imply that the package writer has to
 understand it all IMO.

> 2) the notion that "newer is better" will lead packages to acquire
> useless interface just because it is the most recent version of
> policy.

 Why would the interface be useless?  Say we require nostrip in
 Standards-Version 3.8.0, why would it be useless?

> Build-Options was really meant to be at the option of the packager,
> hence the name Build-Options, and not Build-Standard.

 I don't care that much about the name.  :)  In my proposal,
 Build-Options remain at the option of the packager, and the absence of
 it means "implements the build options required by the
 Standards-Version".

> Policy can enforce new interfaces by itself without the use of
> Build-Options. 

 Yes, but it's not happening: the usual complaints is that this would
 make a lot of packages RC buggy or that this places a high burden on
 the packager.  What I think we could improve via Build-Options:
 - gather good metrics of how many packages implement an interface
 - start using supported Build-Options before they are required by
   policy

> > 4) to document that the absence of a Build-Options field means
> >    "Build-Options: standard"
> 
> Then what is the point of "standard" ? To allow package to not implement
> a Build-Options by using Build-Options: nostandard ? This seems backward.

 No, the point is to have:
    Build-Options: standard, nostrip, build-arch

 So that it's explicit that the build options required by policy are
 implemented.  This is because I find it clearer than only listing
 additionally supported Build-Options.

> As I said I do not like to conflate them: build-arch describe the
> interface to build binary packages suitable for the main archive
> by developers and buildd.
> 
> nostrip/noopt describe ways to build debugging packages that should not
> be uploaded to the main archive. If the option is not implement, policy
> require that the package is build normally.

 A lot of the discussions in #218893 and friends were on *detection* of
 the build options a package supports.  Even if a package implements
 build-arch, the buildd will still be able to build packages in the
 traditional way implemented now, so effectively "build-arch" is a build
 option which everybody has, not just buildds, and that you're not
 required to use when building packages, even on buildds.

 I don't think it makes to have differents fields for buildds and rest
 of the world.


 There's a pile of build options which could be interesting for us to
 list in a Build-Options field, and what I would like is simply to have
 this standard way of detecting what a package supports.

-- 
Loïc Minier



Changed Bug title to `Add Build-Options control field' from `add Build-Options as a debian/control field'. Request was from Russ Allbery <rra@debian.org> to control@bugs.debian.org. (Mon, 17 Mar 2008 05:24:32 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. (Wed, 08 Jun 2011 22:36:09 GMT) Full text and rfc822 format available.

Acknowledgement sent to Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Wed, 08 Jun 2011 22:36:09 GMT) Full text and rfc822 format available.

Message #431 received at 218893@bugs.debian.org (full text, mbox):

From: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>
To: 218893@bugs.debian.org
Subject: Re: Bug#218893: Proposal: Build-Features [Fix for the build-arch problem]
Date: Thu, 9 Jun 2011 00:33:52 +0200
[Message part 1 (text/plain, inline)]
Dear developers,

The attached patch documents the new 'Build-Features: build-arch' control field
in dpkg 1.16.1. This is an updated version of a patch already proposed in
bug #218893 on 12 Nov 2003. The only change is that Build-Options was renamed
to Build-Features by Raphaël Hertzog.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 
[patch (text/plain, attachment)]
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. (Wed, 08 Jun 2011 22:48:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Wed, 08 Jun 2011 22:48:03 GMT) Full text and rfc822 format available.

Message #436 received at 218893@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>
Cc: 218893@bugs.debian.org
Subject: Re: Bug#218893: Proposal: Build-Features [Fix for the build-arch problem]
Date: Wed, 08 Jun 2011 15:45:25 -0700
Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr> writes:

> Dear developers,

> The attached patch documents the new 'Build-Features: build-arch'
> control field in dpkg 1.16.1. This is an updated version of a patch
> already proposed in bug #218893 on 12 Nov 2003. The only change is that
> Build-Options was renamed to Build-Features by Raphaël Hertzog.

For the record (and for anyone following this bug), we should hold on
action on this until the TC decides the way forward for build-arch.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. (Thu, 30 Jun 2011 21:24:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Thu, 30 Jun 2011 21:24:04 GMT) Full text and rfc822 format available.

Message #441 received at 218893@bugs.debian.org (full text, mbox):

From: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>
To: Russ Allbery <rra@debian.org>, 218893@bugs.debian.org
Subject: Re: Bug#218893: Proposal: Build-Features [Fix for the build-arch problem]
Date: Thu, 30 Jun 2011 23:21:31 +0200
On Wed, Jun 08, 2011 at 03:45:25PM -0700, Russ Allbery wrote:
> Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr> writes:
> 
> > Dear developers,
> 
> > The attached patch documents the new 'Build-Features: build-arch'
> > control field in dpkg 1.16.1. This is an updated version of a patch
> > already proposed in bug #218893 on 12 Nov 2003. The only change is that
> > Build-Options was renamed to Build-Features by Raphaël Hertzog.
> 
> For the record (and for anyone following this bug), we should hold on
> action on this until the TC decides the way forward for build-arch.

Note that I did not ask for second.
However lintian does not appear to be exercising such restrain:

W: popularity-contest source: debian-rules-missing-recommended-target build-arch
N:
N:   The debian/rules file for this package does not provide one of the
N:   recommended targets. All of build-arch and build-indep should be
N:   provided, even if they don't do anything for this package. If this
N:   package does not currently split building of architecture dependent
N:   and independent packages, the following rules may be added to fall
N:   back to the build target:
N:
N:     build-arch: build
N:     build-indep: build
N:
N:   Note that the following form is recommended however:
N:
N:     build: build-arch build-indep
N:     build-arch: build-stamp
N:     build-indep: build-stamp
N:     build-stamp:
N:   build here
N:
N:   These targets will be required by policy in the future, so should be
N:   added to prevent future breakage.

This is happens even for package that build a single binary whether arch-all or arch-indep,
which does not seems terribly useful.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. (Thu, 30 Jun 2011 21:45:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Thu, 30 Jun 2011 21:45:03 GMT) Full text and rfc822 format available.

Message #446 received at 218893@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>
Cc: 218893@bugs.debian.org
Subject: Re: Bug#218893: Proposal: Build-Features [Fix for the build-arch problem]
Date: Thu, 30 Jun 2011 14:41:11 -0700
Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr> writes:

> Note that I did not ask for second.
> However lintian does not appear to be exercising such restrain:

[...]

> This is happens even for package that build a single binary whether
> arch-all or arch-indep, which does not seems terribly useful.

It's a warning, not an error.  I do think that providing those targets is
best practice.  If enough packages move in that direction, we can make the
targets mandatory, just like binary-arch and binary-indep, in time.
That's by far the simplest solution to this problem.

The other advantage of Lintian warning on this is that it means we're now
collecting that data for the whole archive.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. (Thu, 30 Jun 2011 22:21:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Thu, 30 Jun 2011 22:21:03 GMT) Full text and rfc822 format available.

Message #451 received at 218893@bugs.debian.org (full text, mbox):

From: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>
To: Russ Allbery <rra@debian.org>
Cc: 218893@bugs.debian.org
Subject: Re: Bug#218893: Proposal: Build-Features [Fix for the build-arch problem]
Date: Fri, 1 Jul 2011 00:18:53 +0200
On Thu, Jun 30, 2011 at 02:41:11PM -0700, Russ Allbery wrote:
> Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr> writes:
> > On Wed, Jun 08, 2011 at 03:45:25PM -0700, Russ Allbery wrote:
>
> > > For the record (and for anyone following this bug), we should hold on
> > > action on this until the TC decides the way forward for build-arch.
>
> > Note that I did not ask for second.
> > However lintian does not appear to be exercising such restrain:
> 
> The other advantage of Lintian warning on this is that it means we're now
> collecting that data for the whole archive.

Not my point.  Maybe you missed the line

N:   These targets will be required by policy in the future, so should be
N:   added to prevent future breakage.

which is basically assuming the outcome (and leads the reader to believe that 
a decision has been reached while the issue is still under discussion).

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. (Thu, 30 Jun 2011 23:27:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Roger Leigh <rleigh@codelibre.net>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Thu, 30 Jun 2011 23:27:04 GMT) Full text and rfc822 format available.

Message #456 received at 218893@bugs.debian.org (full text, mbox):

From: Roger Leigh <rleigh@codelibre.net>
To: 218893@bugs.debian.org
Subject: Re: Bug#218893: Proposal: Build-Features [Fix for the build-arch problem]
Date: Fri, 1 Jul 2011 00:25:37 +0100
[Message part 1 (text/plain, inline)]
On Fri, Jul 01, 2011 at 12:18:53AM +0200, Bill Allombert wrote:
> On Thu, Jun 30, 2011 at 02:41:11PM -0700, Russ Allbery wrote:
> > Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr> writes:
> > > On Wed, Jun 08, 2011 at 03:45:25PM -0700, Russ Allbery wrote:
> >
> > > > For the record (and for anyone following this bug), we should hold on
> > > > action on this until the TC decides the way forward for build-arch.
> >
> > > Note that I did not ask for second.
> > > However lintian does not appear to be exercising such restrain:
> > 
> > The other advantage of Lintian warning on this is that it means we're now
> > collecting that data for the whole archive.
> 
> Not my point.  Maybe you missed the line
> 
> N:   These targets will be required by policy in the future, so should be
> N:   added to prevent future breakage.
> 
> which is basically assuming the outcome (and leads the reader to believe that 
> a decision has been reached while the issue is still under discussion).

As the author of the above, apologies if this was too presumptive.

However, it was my understanding from the discussion that the
proposals being discussed here are basically about how best to
realise the goal of having build-arch and build-indep implemented;
I thought that the goal itself was relatively uncontroversial, but
the means of achieving it were still under discussion.

The lintian text can easily be changed if needed.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. (Thu, 30 Jun 2011 23:36:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Thu, 30 Jun 2011 23:36:03 GMT) Full text and rfc822 format available.

Message #461 received at 218893@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>
Cc: 218893@bugs.debian.org
Subject: Re: Bug#218893: Proposal: Build-Features [Fix for the build-arch problem]
Date: Thu, 30 Jun 2011 16:32:04 -0700
Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr> writes:
> On Thu, Jun 30, 2011 at 02:41:11PM -0700, Russ Allbery wrote:

>> The other advantage of Lintian warning on this is that it means we're
>> now collecting that data for the whole archive.

> Not my point.  Maybe you missed the line

> N:   These targets will be required by policy in the future, so should be
> N:   added to prevent future breakage.

> which is basically assuming the outcome (and leads the reader to believe
> that a decision has been reached while the issue is still under
> discussion).

Ah, okay.  Yes, that's probably premature.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. (Thu, 30 Jun 2011 23:36:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Thu, 30 Jun 2011 23:36:05 GMT) Full text and rfc822 format available.

Message #466 received at 218893@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: Roger Leigh <rleigh@codelibre.net>
Cc: 218893@bugs.debian.org
Subject: Re: Bug#218893: Proposal: Build-Features [Fix for the build-arch problem]
Date: Thu, 30 Jun 2011 16:33:19 -0700
Roger Leigh <rleigh@codelibre.net> writes:

> However, it was my understanding from the discussion that the proposals
> being discussed here are basically about how best to realise the goal of
> having build-arch and build-indep implemented; I thought that the goal
> itself was relatively uncontroversial, but the means of achieving it
> were still under discussion.

Bill has said that he doesn't agree with the long-term goal of making the
targets mandatory.  So far as I know, he's the only one who's said that in
the discussion, but he's right that the tech-ctte hasn't made a decision
on that yet, and it's probably fair to say that his stated disagreement
does make it controversial.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. (Sat, 09 Jul 2011 22:24:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sat, 09 Jul 2011 22:24:03 GMT) Full text and rfc822 format available.

Message #471 received at 218893@bugs.debian.org (full text, mbox):

From: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>
To: Roger Leigh <rleigh@codelibre.net>, 218893@bugs.debian.org
Subject: Re: Bug#218893: Proposal: Build-Features [Fix for the build-arch problem]
Date: Sun, 10 Jul 2011 00:20:31 +0200
On Fri, Jul 01, 2011 at 12:25:37AM +0100, Roger Leigh wrote:
> On Fri, Jul 01, 2011 at 12:18:53AM +0200, Bill Allombert wrote:
> > On Thu, Jun 30, 2011 at 02:41:11PM -0700, Russ Allbery wrote:
> > > Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr> writes:
> > > > On Wed, Jun 08, 2011 at 03:45:25PM -0700, Russ Allbery wrote:
> > >
> > > > > For the record (and for anyone following this bug), we should hold on
> > > > > action on this until the TC decides the way forward for build-arch.
> > >
> > > > Note that I did not ask for second.
> > > > However lintian does not appear to be exercising such restrain:
> > > 
> > > The other advantage of Lintian warning on this is that it means we're now
> > > collecting that data for the whole archive.
> > 
> > Not my point.  Maybe you missed the line
> > 
> > N:   These targets will be required by policy in the future, so should be
> > N:   added to prevent future breakage.
> > 
> > which is basically assuming the outcome (and leads the reader to believe that 
> > a decision has been reached while the issue is still under discussion).
> 
> As the author of the above, apologies if this was too presumptive.
> 
> However, it was my understanding from the discussion that the
> proposals being discussed here are basically about how best to
> realise the goal of having build-arch and build-indep implemented;
> I thought that the goal itself was relatively uncontroversial, but
> the means of achieving it were still under discussion.

If you want that, create a policy proposal to that effect, CC debian-devel, foster
a constructive discussion and get two seconds, so a real consensus can be
reached. So far, about 3 developpers voiced an opinion. This is insufficient.

I am all for implementing the build-arch/build-indep split properly (I
implemented the initial dh-make template for build-arch/build-indep split which
a large number of debian/rules is still based).
However, asking source packages that build only one of arch-all/arch-indep to
implement build-arch/build-indep is useless and a waste of effort. This will
train developers to add
build-arch: build
build-indep: build
to debian/rules without further consideration.

Instead we should focus on the smaller number of packages that provide both
arch-all/arch-indep and make sure build-arch actually only build the arch-all
part and build-indep the arch-indep part.
We could use that opportunuity to implement Build-Options: build-arch and
proper Build-Depends/Build-Depends-Indep split.

Then we would have achieved something. Just adding build-arch: build to all packages
does not.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#218893; Package debian-policy. (Sat, 09 Jul 2011 23:30:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Roger Leigh <rleigh@codelibre.net>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sat, 09 Jul 2011 23:30:06 GMT) Full text and rfc822 format available.

Message #476 received at 218893@bugs.debian.org (full text, mbox):

From: Roger Leigh <rleigh@codelibre.net>
To: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>, 218893@bugs.debian.org, debian-ctte@lists.debian.org
Subject: Re: Bug#218893: Proposal: Build-Features [Fix for the build-arch problem]
Date: Sun, 10 Jul 2011 00:26:35 +0100
[Message part 1 (text/plain, inline)]
On Sun, Jul 10, 2011 at 12:20:31AM +0200, Bill Allombert wrote:
> On Fri, Jul 01, 2011 at 12:25:37AM +0100, Roger Leigh wrote:
> > On Fri, Jul 01, 2011 at 12:18:53AM +0200, Bill Allombert wrote:
> > > On Thu, Jun 30, 2011 at 02:41:11PM -0700, Russ Allbery wrote:
> > > > Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr> writes:
> > > > > On Wed, Jun 08, 2011 at 03:45:25PM -0700, Russ Allbery wrote:
> > > >
> > > > > > For the record (and for anyone following this bug), we should hold on
> > > > > > action on this until the TC decides the way forward for build-arch.
> > > >
> > > > > Note that I did not ask for second.
> > > > > However lintian does not appear to be exercising such restrain:
> > > > 
> > > > The other advantage of Lintian warning on this is that it means we're now
> > > > collecting that data for the whole archive.
> > > 
> > > Not my point.  Maybe you missed the line
> > > 
> > > N:   These targets will be required by policy in the future, so should be
> > > N:   added to prevent future breakage.
> > > 
> > > which is basically assuming the outcome (and leads the reader to believe that 
> > > a decision has been reached while the issue is still under discussion).
> > 
> > As the author of the above, apologies if this was too presumptive.
> > 
> > However, it was my understanding from the discussion that the
> > proposals being discussed here are basically about how best to
> > realise the goal of having build-arch and build-indep implemented;
> > I thought that the goal itself was relatively uncontroversial, but
> > the means of achieving it were still under discussion.
> 
> If you want that, create a policy proposal to that effect, CC debian-devel, foster
> a constructive discussion and get two seconds, so a real consensus can be
> reached. So far, about 3 developpers voiced an opinion. This is insufficient.
> 
> I am all for implementing the build-arch/build-indep split properly (I
> implemented the initial dh-make template for build-arch/build-indep split which
> a large number of debian/rules is still based).
> However, asking source packages that build only one of arch-all/arch-indep to
> implement build-arch/build-indep is useless and a waste of effort. This will
> train developers to add
> build-arch: build
> build-indep: build
> to debian/rules without further consideration.
> 
> Instead we should focus on the smaller number of packages that provide both
> arch-all/arch-indep and make sure build-arch actually only build the arch-all
> part and build-indep the arch-indep part.
> We could use that opportunuity to implement Build-Options: build-arch and
> proper Build-Depends/Build-Depends-Indep split.
> 
> Then we would have achieved something. Just adding build-arch: build to all packages
> does not.

This is something which the -ctte might want to bear in mind in their
considerations.  It's probably best to wait until the current issue
(dpkg-buildpackage support for build-arch/indep) is finished before
making further changes to lintian.

Personally, I'd like to aim for complete support archive-wide.  It
means everything is consistent, and it means all the binary targets
have a corresponding build target.  Overall, it simplifies things and
will in the long run make our tools more capable and robust.  We do
require all packages to implement binary-arch/indep irrespective of
the package types being built, and IMO we should make the same
requirement of build-arch/indep.

There is no harm in encouraging adoption of the targets!


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.
[signature.asc (application/pgp-signature, inline)]

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Sun Apr 20 01:55:59 2014; Machine Name: buxtehude.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.