Re: Can we require build-arch/indep targets for lenny?

[Florent Rougon]

Hi,

Goswin von Brederlow <[EMAIL PROTECTED]> wrote:

> I would like to gather up some momentum for a policy change. Namely
> that the build-arch/indep targets in debian/rules become required
> instead of being optional.

FWIW, I think that would be a good thing (I remember a discussion with
you on -mentors on Build-Depends v.s. Build-Depends-Indep whose outcome
was that the real problem was that build-arch and build-indep are
optional).

-- 
Florent


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Can we require build-arch/indep targets for lenny?

[Thomas Viehmann]

Goswin von Brederlow wrote:

I would like to gather up some momentum for a policy change. Namely
that the build-arch/indep targets in debian/rules become required
instead of being optional.

Wouldn't looking for the output
  make: *** No rule to make target `build-arch'.  Stop.
and then defaulting to make build be an option?


Possible upgrade paths:

4) Make build-arch/indep recommended and have lintian issue a warning.

Kind regards

T.
--
Thomas Viehmann, http://thomas.viehmann.net/


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Can we require build-arch/indep targets for lenny?

[Daniel Schepler]

On Monday 18 June 2007 04:30:55 am Goswin von Brederlow wrote:
> Hi,
>
> I would like to gather up some momentum for a policy change. Namely
> that the build-arch/indep targets in debian/rules become required
> instead of being optional.
>
> The reason for this is that dpkg-buildpackage can't reliable detect
> the existance of the build-arch/indep targets and must call 'build'
> instead. This forces every source to compile both architecture
> specific and architecture independent code on all buildds and
> increases the Build-Depends of packages a lot.

How about instead requiring something like: the build-arch target must return 
successfully or with a status of 2 (the standard make error status 
for "target not found"), and in the latter case the build target must return 
successfully.  That is, if Build-Depends but not necessarily 
Build-Depends-Indep are installed, the shell snippet

  debian/rules build-arch || (test $? -eq 2 && debian/rules build)

must work and exit with a status of 0.

This would make it possible for dpkg-buildpackage -B to be reliable while 
allowing most (or even all?) of the current packages to stay as they are 
until maintainers can add the recommended build-arch target.
-- 
Daniel Schepler


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Can we require build-arch/indep targets for lenny?

[Wouter Verhelst]

On Mon, Jun 18, 2007 at 04:40:26PM +0200, Thomas Viehmann wrote:
> Goswin von Brederlow wrote:
> >I would like to gather up some momentum for a policy change. Namely
> >that the build-arch/indep targets in debian/rules become required
> >instead of being optional.
> Wouldn't looking for the output
>   make: *** No rule to make target `build-arch'.  Stop.
> and then defaulting to make build be an option?

make: *** Er is geen regel om 'build-arch' te maken.  Gestopt.

Yes, you can use LC_ALL=C, but some people do strange things to their
environment. The point is that parsing output that isn't meant for
machine consumption is usually a bad idea.

OTOH, this is trivial:

build-indep: build
build-arch: build
build:
foo
bar
baz

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Can we require build-arch/indep targets for lenny?

[Wouter Verhelst]

On Mon, Jun 18, 2007 at 12:25:38PM -0400, Daniel Schepler wrote:
> How about instead requiring something like: the build-arch target must return 
> successfully or with a status of 2 (the standard make error status 
> for "target not found"), and in the latter case the build target must return 
> successfully.  That is, if Build-Depends but not necessarily 
> Build-Depends-Indep are installed, the shell snippet
> 
>   debian/rules build-arch || (test $? -eq 2 && debian/rules build)
> 
> must work and exit with a status of 0.
> 
> This would make it possible for dpkg-buildpackage -B to be reliable while 
> allowing most (or even all?) of the current packages to stay as they are 
> until maintainers can add the recommended build-arch target.

That has been tried, but it didn't work for some reason.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Can we require build-arch/indep targets for lenny?

[Bill Allombert]

On Mon, Jun 18, 2007 at 10:30:55AM +0200, Goswin von Brederlow wrote:
> Hi,
> 
> I would like to gather up some momentum for a policy change. Namely
> that the build-arch/indep targets in debian/rules become required
> instead of being optional.
> 
> The reason for this is that dpkg-buildpackage can't reliable detect
> the existance of the build-arch/indep targets and must call 'build'
> instead. This forces every source to compile both architecture
> specific and architecture independent code on all buildds and
> increases the Build-Depends of packages a lot.

I suggest anyone reread the bug log for #218893 that give a
full account of the problem before commenting.

My preference is for the dpkg maintainers to apply the patch in the
buglog #229357, or at least reply to it.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Can we require build-arch/indep targets for lenny?

[Goswin von Brederlow]

Wouter Verhelst <[EMAIL PROTECTED]> writes:

> On Mon, Jun 18, 2007 at 04:40:26PM +0200, Thomas Viehmann wrote:
>> Goswin von Brederlow wrote:
>> >I would like to gather up some momentum for a policy change. Namely
>> >that the build-arch/indep targets in debian/rules become required
>> >instead of being optional.
>> Wouldn't looking for the output
>>   make: *** No rule to make target `build-arch'.  Stop.
>> and then defaulting to make build be an option?
>
> make: *** Er is geen regel om 'build-arch' te maken.  Gestopt.
>
> Yes, you can use LC_ALL=C, but some people do strange things to their
> environment. The point is that parsing output that isn't meant for
> machine consumption is usually a bad idea.

Better to check for error code 2. But again, it isn't definitiv.

You would get some false positive.

> OTOH, this is trivial:
>
> build-indep: build
> build-arch: build
> build:
>   foo
>   bar
>   baz

Indeed.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Can we require build-arch/indep targets for lenny?

[Goswin von Brederlow]

Daniel Schepler <[EMAIL PROTECTED]> writes:

> On Monday 18 June 2007 04:30:55 am Goswin von Brederlow wrote:
>> Hi,
>>
>> I would like to gather up some momentum for a policy change. Namely
>> that the build-arch/indep targets in debian/rules become required
>> instead of being optional.
>>
>> The reason for this is that dpkg-buildpackage can't reliable detect
>> the existance of the build-arch/indep targets and must call 'build'
>> instead. This forces every source to compile both architecture
>> specific and architecture independent code on all buildds and
>> increases the Build-Depends of packages a lot.
>
> How about instead requiring something like: the build-arch target must return 
> successfully or with a status of 2 (the standard make error status 
> for "target not found"), and in the latter case the build target must return 
> successfully.  That is, if Build-Depends but not necessarily 
> Build-Depends-Indep are installed, the shell snippet

That is already required by policy.

What is missing is that nothing else may return an error of 2 and I
think that is a bad idea to require.

>   debian/rules build-arch || (test $? -eq 2 && debian/rules build)
>
> must work and exit with a status of 0.

Which causes double builds in case something fails with error 2.

> This would make it possible for dpkg-buildpackage -B to be reliable while 
> allowing most (or even all?) of the current packages to stay as they are 
> until maintainers can add the recommended build-arch target.

The target has been recommended for years. But nobody is adding it
because it can't be used reliably by the tools.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Can we require build-arch/indep targets for lenny?

[Goswin von Brederlow]

Bill Allombert <[EMAIL PROTECTED]> writes:

> On Mon, Jun 18, 2007 at 10:30:55AM +0200, Goswin von Brederlow wrote:
>> Hi,
>> 
>> I would like to gather up some momentum for a policy change. Namely
>> that the build-arch/indep targets in debian/rules become required
>> instead of being optional.
>> 
>> The reason for this is that dpkg-buildpackage can't reliable detect
>> the existance of the build-arch/indep targets and must call 'build'
>> instead. This forces every source to compile both architecture
>> specific and architecture independent code on all buildds and
>> increases the Build-Depends of packages a lot.
>
> I suggest anyone reread the bug log for #218893 that give a
> full account of the problem before commenting.
>
> My preference is for the dpkg maintainers to apply the patch in the
> buglog #229357, or at least reply to it.
>
> Cheers,

Which are both DEAD. Both decided by indecision and silence to not
act.

So do we call the tech committe to force a decision?


As a note I don't think it is the dpkg maintainers choice to make
here. They can veto on the feasibility and on the implementation, the
technical aspect, but I think the debian developers as a whole have
the right to make policy that even dpkg maintainers must follow.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Can we require build-arch/indep targets for lenny?

[Antti-Juhani Kaijanaho]

On Mon, Jun 18, 2007 at 04:40:26PM +0200, Thomas Viehmann wrote:
> Wouldn't looking for the output
>   make: *** No rule to make target `build-arch'.  Stop.
> and then defaulting to make build be an option?

This was discussed and rejected back when the build-* targets were proposed.

-- 
Antti-Juhani Kaijanaho, Jyväskylä
http://antti-juhani.kaijanaho.fi/newblog/


signature.asc
Description: Digital signature

Re: Can we require build-arch/indep targets for lenny?

[Simon Huggins]

On Tue, Jun 19, 2007 at 11:18:18AM +0200, Goswin von Brederlow wrote:
> So do we call the tech committe to force a decision?

Perhaps you could try talking to the people concerned (not via a bug,
perhaps on IRC or in person or private mail) first?

Simon.

-- 
[ If at first you don't succeed, destroy all evidence that you tried.  ]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Can we require build-arch/indep targets for lenny?

[Bill Allombert]

On Tue, Jun 19, 2007 at 03:04:30PM +0100, Simon Huggins wrote:
> On Tue, Jun 19, 2007 at 11:18:18AM +0200, Goswin von Brederlow wrote:
> > So do we call the tech committe to force a decision?
> 
> Perhaps you could try talking to the people concerned (not via a bug,
> perhaps on IRC or in person or private mail) first?

In 3 years and a half, I had the time to try all of that...
So I will try something new: an online petition:

If you would like bug #229357 to get an answer, please
send a signed email to the buglog.

At least, I would feel less alone.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Can we require build-arch/indep targets for lenny?

[Josip Rodin]

On Tue, Jun 19, 2007 at 10:47:24AM +0200, Goswin von Brederlow wrote:
> >   debian/rules build-arch || (test $? -eq 2 && debian/rules build)
> >
> > must work and exit with a status of 0.
> 
> Which causes double builds in case something fails with error 2.

How often does something fail with error 2? Can someone try that over
the whole archive, and produce a statistic?

I'm thinking we are being too concerned with what seems likely to be
a corner case. It makes sense to either substantiate that concern or
ignore it; this kind of a limbo is pointless.

-- 
 2. That which causes joy or happiness.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Can we require build-arch/indep targets for lenny?

[Ian Jackson]

Bill Allombert writes ("Re: Can we require build-arch/indep targets for 
lenny?"):
> In 3 years and a half, I had the time to try all of that...
> So I will try something new: an online petition:
> 
> If you would like bug #229357 to get an answer, please
> send a signed email to the buglog.

Please, this is no way to carry on.

> At least, I would feel less alone.

FWIW, I agree with you.  I think the proposed `Build-Options' source
control field is a sensible addition and the bug should be implemented
immediately.

Obviously the dpkg developers are rather busy at the moment.  I think
that the right thing to do is to offer to NMU.

While we are at it we should write a specification for Build-Options,
something like:

  The Build-Options field appears (only) in the first stanza in
  debian/control.  It gives a whitespace-separated list of options.
  The meanings of these options is defined in policy.

  Any package processing tool may act only on options which it
  recognises.  Unknown tokens must be ignored.

  Currently only the following token is defined:

  * build-arch
Declares that the package supports all of the following
build targets: `build-indep', `build-arch', `binary-indep',
`binary-arch'.

Ian.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Can we require build-arch/indep targets for lenny?

[Bill Allombert]

On Tue, Jun 26, 2007 at 02:33:26PM +0100, Ian Jackson wrote:
> Bill Allombert writes ("Re: Can we require build-arch/indep targets for 
> lenny?"):
> > In 3 years and a half, I had the time to try all of that...
> > So I will try something new: an online petition:
> > 
> > If you would like bug #229357 to get an answer, please
> > send a signed email to the buglog.
> 
> Please, this is no way to carry on.

Ironically, you are the only one to do that so far, the fact that you
did not sign your post notwithstanding.

> > At least, I would feel less alone.
> 
> FWIW, I agree with you.  I think the proposed `Build-Options' source
> control field is a sensible addition and the bug should be implemented
> immediately.
> 
> Obviously the dpkg developers are rather busy at the moment.  I think
> that the right thing to do is to offer to NMU.

So I hereby offer to do a NMU by applying this patch.

> While we are at it we should write a specification for Build-Options,
> something like:
> 
>   The Build-Options field appears (only) in the first stanza in
>   debian/control.  It gives a whitespace-separated list of options.
>   The meanings of these options is defined in policy.
> 
>   Any package processing tool may act only on options which it
>   recognises.  Unknown tokens must be ignored.
> 
>   Currently only the following token is defined:
> 
>   * build-arch
> Declares that the package supports all of the following
> build targets: `build-indep', `build-arch', `binary-indep',
> `binary-arch'.

Note: binary-indep and binary-arch are already mandatory according to
Debian policy 4.9. 

The specification are included in the patch to debian-policy in bug
#218893, msgid <[EMAIL PROTECTED]>, specifically

+
+Build-Options
+
+   The syntax is a list of options separated by
+  commas that are implemented in the build process.
+   The following options are defined:
+   
+  build-arch The optional targets "build-arch"
+ and "build-indep" are implemented by debian/rules
+ as defined in .  
+   
+
+

Thanks for yours answer,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Can we require build-arch/indep targets for lenny?

[Joey Hess]

Ian Jackson wrote:
> While we are at it we should write a specification for Build-Options,
> something like:
> 
>   The Build-Options field appears (only) in the first stanza in
>   debian/control.  It gives a whitespace-separated list of options.
>   The meanings of these options is defined in policy.
> 
>   Any package processing tool may act only on options which it
>   recognises.  Unknown tokens must be ignored.
> 
>   Currently only the following token is defined:
> 
>   * build-arch
> Declares that the package supports all of the following
> build targets: `build-indep', `build-arch', `binary-indep',
> `binary-arch'.

Funny, I'd forgotten this was ever proposed before, and was planning to
propose adding a Build-Options field for entirely other, though fully
compatible reasons. Which suggests that the name and format are well
chosen.

I think it would also be useful to include 'nostrip' and 'noopt' in the
Build-Options field, as a way to indicate that the package implements
those DEB_BUILD_OPTIONS. I also have some Evil Plans for other things
that can go in Build-Options, but they're not ready yet and would be OT
in this thread.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Can we require build-arch/indep targets for lenny?

[Joey Hess]

Bill Allombert wrote:
> +   The syntax is a list of options separated by
> +  commas that are implemented in the build process.
> +   The following options are defined:

If commas are used as delimiters, it should use ", " as the delimiter
for consistency with other fields using commas as delimiters. Since
debian/control has both space and comma-delimited fields, I have no real
preference which is chosen.

Also, I like Ian's language about all unknown fields being ignored.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Can we require build-arch/indep targets for lenny?

[Russ Allbery]

Joey Hess <[EMAIL PROTECTED]> writes:

> I think it would also be useful to include 'nostrip' and 'noopt' in the
> Build-Options field, as a way to indicate that the package implements
> those DEB_BUILD_OPTIONS.

parallel=n as well, while we're at it.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Can we require build-arch/indep targets for lenny?

[Loïc Minier]

On Tue, Jun 26, 2007, Joey Hess wrote:
> I think it would also be useful to include 'nostrip' and 'noopt' in the
> Build-Options field, as a way to indicate that the package implements
> those DEB_BUILD_OPTIONS. I also have some Evil Plans for other things
> that can go in Build-Options, but they're not ready yet and would be OT
> in this thread.

 Why not promote these to requirements in a particular policy version
 instead?  I fear we will have to list 10 Build-Options in all packages
 in a couple of years.

-- 
Loïc Minier


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Can we require build-arch/indep targets for lenny?

[Russ Allbery]

Loïc Minier <[EMAIL PROTECTED]> writes:
> On Tue, Jun 26, 2007, Joey Hess wrote:

>> I think it would also be useful to include 'nostrip' and 'noopt' in the
>> Build-Options field, as a way to indicate that the package implements
>> those DEB_BUILD_OPTIONS. I also have some Evil Plans for other things
>> that can go in Build-Options, but they're not ready yet and would be OT
>> in this thread.

>  Why not promote these to requirements in a particular policy version
>  instead?  I fear we will have to list 10 Build-Options in all packages
>  in a couple of years.

Currently, policy says that it's recommended (the weakest policy
directive) to support noopt and nostrip.  My main concern with increasing
the strength of that directive is that, depending on how demented the
upstream build system is, it can be difficult to support these options,
and since neither is used for regular builds in Debian, they're not
usually tested and aren't necessary for properly functioning packages.

-- 
Russ Allbery ([EMAIL PROTECTED])   

Re: Can we require build-arch/indep targets for lenny?

[Ben Pfaff]

Russ Allbery <[EMAIL PROTECTED]> writes:

> Currently, policy says that it's recommended (the weakest policy
> directive) to support noopt and nostrip.  My main concern with increasing
> the strength of that directive is that, depending on how demented the
> upstream build system is, it can be difficult to support these options,
> and since neither is used for regular builds in Debian, they're not
> usually tested and aren't necessary for properly functioning packages.

I have a little bit of experience with recompiling packages to
include debug symbols.  In that little of experience I found that
the easiest way to do it was to put a set of wrapper programs in
$PATH that ensured that compilers added debug symbols and that
programs and options to remove them were ignored.  I wonder
whether this general approach would be better than requiring each
package maintainer to implement a pair of build-time options.
The most obvious trouble I can see with it is packages that
invoke tools through absolute paths or reset $PATH themselves.

(I haven't followed previous discussion of these options.  If
this approach has already been considered and discounted, please
ignore me.)
-- 
Ben Pfaff 
http://benpfaff.org


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Can we require build-arch/indep targets for lenny?

[Steve Langasek]

On Mon, Jun 18, 2007 at 10:30:55AM +0200, Goswin von Brederlow wrote:
> I would like to gather up some momentum for a policy change. Namely
> that the build-arch/indep targets in debian/rules become required
> instead of being optional.

> The reason for this is that dpkg-buildpackage can't reliable detect
> the existance of the build-arch/indep targets and must call 'build'
> instead. This forces every source to compile both architecture
> specific and architecture independent code on all buildds and
> increases the Build-Depends of packages a lot.

> Current status:

> I asked Lucas Nussbaum to rebuild all of debian with dpkg-buildpackage
> patched to call 'build-arch'. Here is the result:

> 7326 packages rebuilt (all packages not Architecture:all)
> 1727 built successfully
> 5463 failed to build with a "no rule to make" error.
> 136 failed for other reasons (unsat builddeps, etc)

> That means that only about 25% of debian package have a build-arch
> target. So there is still a long way to got.

> Possible upgrade paths:

> 1) Change policy now making 75% of package RC buggy instantly.

>This sounds horrible but the fix is trivial and there is still a
>long time to lenny to fix it.

No, the fix is not trivial; you will not get the buildd maintainers to
implement such a change when it makes 75% of the archive unbuildable, and
without such pressure you will never reach 100% adoption by package
maintainers.

Any serious adoption path needs to get used in the near term, to avoid the
package support for it atrophying due to disuse, while not breaking the
packages that have not yet implemented it.

> 2) Enforce the target for all new uploads and change policy once we
>exceed XX%.

>The unstable/experimental buildds could be patched to call
>'build-arch' instead of build making any upload without
>'build-arch' FTBFS. The security buildds would be left
>as is so nothing old breaks.

Again, very impractical, particularly for transitions where binNMUs are
involved.

> 3) Require 'build-arch/indep' with Standards-Version x.y.z

>Every source has a Standards-Version entry. dpkg-buildpackage could
>call 'build-arch' if the standards version is new enough and fall
>back to 'build' for older versions.

That's an option, but doesn't even let us take advantage of build-arch
support for existing packages that reference an older Standards-Version.

Whatever happened to the idea of using make options to check for the
existence of a target in debian/rules?  IIRC we have a total of one package
in the archive that stubbornly refuses to comply with Policy 4.9
(debian/rules must be a makefile), so if we're entertaining solutions that
make existing packages buggy, why would we not use the method that minimizes
the number of packages that will be broken in the process?

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Can we require build-arch/indep targets for lenny?

[Goswin von Brederlow]

Steve Langasek <[EMAIL PROTECTED]> writes:

> On Mon, Jun 18, 2007 at 10:30:55AM +0200, Goswin von Brederlow wrote:
>> I would like to gather up some momentum for a policy change. Namely
>> that the build-arch/indep targets in debian/rules become required
>> instead of being optional.
>
>> The reason for this is that dpkg-buildpackage can't reliable detect
>> the existance of the build-arch/indep targets and must call 'build'
>> instead. This forces every source to compile both architecture
>> specific and architecture independent code on all buildds and
>> increases the Build-Depends of packages a lot.
>
>> Current status:
>
>> I asked Lucas Nussbaum to rebuild all of debian with dpkg-buildpackage
>> patched to call 'build-arch'. Here is the result:
>
>> 7326 packages rebuilt (all packages not Architecture:all)
>> 1727 built successfully
>> 5463 failed to build with a "no rule to make" error.
>> 136 failed for other reasons (unsat builddeps, etc)
>
>> That means that only about 25% of debian package have a build-arch
>> target. So there is still a long way to got.
>
>> Possible upgrade paths:
>
>> 1) Change policy now making 75% of package RC buggy instantly.
>
>>This sounds horrible but the fix is trivial and there is still a
>>long time to lenny to fix it.
>
> No, the fix is not trivial; you will not get the buildd maintainers to
> implement such a change when it makes 75% of the archive unbuildable, and
> without such pressure you will never reach 100% adoption by package
> maintainers.

The fix IS trivial. You can't tell me that it is a problem to add
"build-%: build" to your rules file when you are doing an upload
anyway.

Also by changing policy nothing becomes unbuildable as tools would not
yet take advantage of that policy. It just means it would be a bug not
to have the targets.

> Any serious adoption path needs to get used in the near term, to avoid the
> package support for it atrophying due to disuse, while not breaking the
> packages that have not yet implemented it.
>
>> 2) Enforce the target for all new uploads and change policy once we
>>exceed XX%.
>
>>The unstable/experimental buildds could be patched to call
>>'build-arch' instead of build making any upload without
>>'build-arch' FTBFS. The security buildds would be left
>>as is so nothing old breaks.
>
> Again, very impractical, particularly for transitions where binNMUs are
> involved.

I give you that. binNMUs would be a slight problem. The idea predates
binNMUs though so that was never discussed back then.

>> 3) Require 'build-arch/indep' with Standards-Version x.y.z
>
>>Every source has a Standards-Version entry. dpkg-buildpackage could
>>call 'build-arch' if the standards version is new enough and fall
>>back to 'build' for older versions.
>
> That's an option, but doesn't even let us take advantage of build-arch
> support for existing packages that reference an older Standards-Version.

I don't consider that a big deal. We already don't take advantage of
them now. If the majority of packages update to the new standrds
version before lenny that is just fine.

> Whatever happened to the idea of using make options to check for the
> existence of a target in debian/rules?  IIRC we have a total of one package
> in the archive that stubbornly refuses to comply with Policy 4.9
> (debian/rules must be a makefile), so if we're entertaining solutions that
> make existing packages buggy, why would we not use the method that minimizes
> the number of packages that will be broken in the process?

Because detecting has side effects and is costly, if it wrks reliable
at all. See other mails.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Can we require build-arch/indep targets for lenny?

[Ian Jackson]

Russ Allbery writes ("Re: Can we require build-arch/indep targets for lenny?"):
> Lo?c Minier <[EMAIL PROTECTED]> writes:
> >  Why not promote these to requirements in a particular policy version
> >  instead?  I fear we will have to list 10 Build-Options in all packages
> >  in a couple of years.

This is a much better idea.

> Currently, policy says that it's recommended (the weakest policy
> directive) to support noopt and nostrip.  My main concern with increasing
> the strength of that directive is that, depending on how demented the
> upstream build system is, it can be difficult to support these options,
> and since neither is used for regular builds in Debian, they're not
> usually tested and aren't necessary for properly functioning packages.

Surely we are planning to support these options in all packages
eventually ?  In a package where it is difficult to separate out the
work for binary-indep, it would be acceptable to say:
   binary-indep: binary
   binary-arch: binary
   binary: build
   some stuff
?

I'm tempted to suggest _just_ going by the package's Standards-Version.

Ian.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Can we require build-arch/indep targets for lenny?

[Russ Allbery]

Ian Jackson <[EMAIL PROTECTED]> writes:
> Russ Allbery writes ("Re: Can we require build-arch/indep targets for 
> lenny?"):

>> Currently, policy says that it's recommended (the weakest policy
>> directive) to support noopt and nostrip.  My main concern with
>> increasing the strength of that directive is that, depending on how
>> demented the upstream build system is, it can be difficult to support
>> these options, and since neither is used for regular builds in Debian,
>> they're not usually tested and aren't necessary for properly
>> functioning packages.

> Surely we are planning to support these options in all packages
> eventually ?

It is certainly not clear to me that we're planning on supporting nostrip
and noopt for all packages eventually.

> I'm tempted to suggest _just_ going by the package's Standards-Version.

Based on the arguments I've seen so far, I'm opposed to using the
package's Standards-Version for this purpose.  I think it conflates
different meanings of that field and will get us into serious trouble when
it comes to the distinctions between must, should, and recommended.

-- 
Russ Allbery ([EMAIL PROTECTED])   <http://www.eyrie.org/~eagle/>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Can we require build-arch/indep targets for lenny?

[Goswin von Brederlow]

Russ Allbery <[EMAIL PROTECTED]> writes:

>> I'm tempted to suggest _just_ going by the package's Standards-Version.
>
> Based on the arguments I've seen so far, I'm opposed to using the
> package's Standards-Version for this purpose.  I think it conflates
> different meanings of that field and will get us into serious trouble when
> it comes to the distinctions between must, should, and recommended.

| Policy 5.6.11 Standards-Version
|
| The most recent version of the standards (the policy manual and
| associated texts) with which the package complies.

This field has exactly this meaning. It says the package followes a
certain version of policy, e.g. the one where now there is a MUST
instead of the previous RECOMMENDS.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Can we require build-arch/indep targets for lenny?

[Russ Allbery]

Goswin von Brederlow <[EMAIL PROTECTED]> writes:
> Russ Allbery <[EMAIL PROTECTED]> writes:

>> Based on the arguments I've seen so far, I'm opposed to using the
>> package's Standards-Version for this purpose.  I think it conflates
>> different meanings of that field and will get us into serious trouble
>> when it comes to the distinctions between must, should, and
>> recommended.

> | Policy 5.6.11 Standards-Version
> |
> | The most recent version of the standards (the policy manual and
> | associated texts) with which the package complies.

> This field has exactly this meaning. It says the package followes a
> certain version of policy, e.g. the one where now there is a MUST
> instead of the previous RECOMMENDS.

You seem to be ignoring the end of second sentence of my paragraph above,
which I wrote precisely because I anticipated this argument.  Could you
respond to it as well?  Not every feature we care about is going to be a
must.

I would much prefer to see a new control field that explicitly lists the
supported features.  We're going to need that *anyway* for any feature
that's only a should or recommended and not a must (such as supporting
noopt or nostrip), and making every should into a must just so that we can
use this interpretation of Standards-Version is not a solution.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Can we require build-arch/indep targets for lenny?

[Goswin von Brederlow]

Russ Allbery <[EMAIL PROTECTED]> writes:

> Goswin von Brederlow <[EMAIL PROTECTED]> writes:
>> Russ Allbery <[EMAIL PROTECTED]> writes:
>
>>> Based on the arguments I've seen so far, I'm opposed to using the
>>> package's Standards-Version for this purpose.  I think it conflates
>>> different meanings of that field and will get us into serious trouble
>>> when it comes to the distinctions between must, should, and
>>> recommended.
>
>> | Policy 5.6.11 Standards-Version
>> |
>> | The most recent version of the standards (the policy manual and
>> | associated texts) with which the package complies.
>
>> This field has exactly this meaning. It says the package followes a
>> certain version of policy, e.g. the one where now there is a MUST
>> instead of the previous RECOMMENDS.
>
> You seem to be ignoring the end of second sentence of my paragraph above,
> which I wrote precisely because I anticipated this argument.  Could you
> respond to it as well?  Not every feature we care about is going to be a
> must.

I thought you ment that with << ver something is recommended but >>ver
is is must would be a problem.

> I would much prefer to see a new control field that explicitly lists the
> supported features.  We're going to need that *anyway* for any feature
> that's only a should or recommended and not a must (such as supporting
> noopt or nostrip), and making every should into a must just so that we can
> use this interpretation of Standards-Version is not a solution.

So far I have not seen anything that would require it.

The build-arch target should be a must so no extra build option flag
needed.

As for the noopt/nostrip feature. What if the source does not support
them? What can you do? Not set them? That is exatly the same as
setting them and having the source not honor them.
Having a build options flag for noopt and nostrip would be purely
informational. It is not like some functionaly gets lost wthout it
unlike the build-arch target.


By all means fight for buiold-options but I still don't see why we
need this for buila-arch/indep targets. There is no good reason to
keep the optional.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Can we require build-arch/indep targets for lenny?

[Russ Allbery]

Goswin von Brederlow <[EMAIL PROTECTED]> writes:
> Russ Allbery <[EMAIL PROTECTED]> writes:

>> I would much prefer to see a new control field that explicitly lists
>> the supported features.  We're going to need that *anyway* for any
>> feature that's only a should or recommended and not a must (such as
>> supporting noopt or nostrip), and making every should into a must just
>> so that we can use this interpretation of Standards-Version is not a
>> solution.

> So far I have not seen anything that would require it.

I think it would be useful to advertise the optional capabilities of a
package (noopt, nostrip, parallel) without forcing people to do trial and
error.  I suppose that's not a "require," but it certainly would be nice.

> The build-arch target should be a must so no extra build option flag
> needed.

I really don't think that declaring the majority of packages in Debian
buggy in this fashion is viable, particularly when nearly all packages in
Debian will not benefit from this.  My guess is that something on the
order of 1% of packages have a meaningful distinction between build-arch
and build-indep, if that, but that includes some packages that benefit a
*lot*.  Wouldn't it be better to only have to work on modifying the
packages that will specifically benefit instead of making every other
package maintainer in Debian add a new target that really isn't meaningful
for their package?

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Can we require build-arch/indep targets for lenny?

[Goswin von Brederlow]

Russ Allbery <[EMAIL PROTECTED]> writes:

> Goswin von Brederlow <[EMAIL PROTECTED]> writes:
>> Russ Allbery <[EMAIL PROTECTED]> writes:
>
>>> I would much prefer to see a new control field that explicitly lists
>>> the supported features.  We're going to need that *anyway* for any
>>> feature that's only a should or recommended and not a must (such as
>>> supporting noopt or nostrip), and making every should into a must just
>>> so that we can use this interpretation of Standards-Version is not a
>>> solution.
>
>> So far I have not seen anything that would require it.
>
> I think it would be useful to advertise the optional capabilities of a
> package (noopt, nostrip, parallel) without forcing people to do trial and
> error.  I suppose that's not a "require," but it certainly would be nice.

As for parallel I don't think build-options is enough. The amount of
parallelism usefull depends too much on the system and package. For
example a simple C source can build fine with -j4 and 256MB ram. But
any c++ source with templates will just swap to death with the same.

In a discussion last year I suggested providing a tool to ask the
system for the prefered parallelism to be used during compile. The
tool would get a few parameters such as what language is used or how
much ram the compiler roughly needs. It would check that against the
systems config and resources and then reply with a parallelism level
the source could use.

>> The build-arch target should be a must so no extra build option flag
>> needed.
>
> I really don't think that declaring the majority of packages in Debian
> buggy in this fashion is viable, particularly when nearly all packages in
> Debian will not benefit from this.  My guess is that something on the
> order of 1% of packages have a meaningful distinction between build-arch
> and build-indep, if that, but that includes some packages that benefit a
> *lot*.  Wouldn't it be better to only have to work on modifying the
> packages that will specifically benefit instead of making every other
> package maintainer in Debian add a new target that really isn't meaningful
> for their package?

Already 25% of all packages do have the targets and I assume a lot
more than 1% to benefit. If one single Build-Depends can be moved into
Build-Depends-Indep that is already a benefit.

Weigh that against the cost, adding a % to the build target or adding
'build-%: build', for the packages without meaningful distinction. I
just feel that the cost is so small that any smarter solution than
just requiring build-arch/indep tragets is more waste.

And yes, 75% of the archive would become theoretically buggy the
instance we declare it a must. But nothing breaks and nothing is
actually buggy unless the standards-version gets increased by the
maintainer. At least that is how I see it.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Can we require build-arch/indep targets for lenny?

[Russ Allbery]

Goswin von Brederlow <[EMAIL PROTECTED]> writes:
> Russ Allbery <[EMAIL PROTECTED]> writes:

>> I really don't think that declaring the majority of packages in Debian
>> buggy in this fashion is viable, particularly when nearly all packages
>> in Debian will not benefit from this.  My guess is that something on
>> the order of 1% of packages have a meaningful distinction between
>> build-arch and build-indep, if that, but that includes some packages
>> that benefit a *lot*.  Wouldn't it be better to only have to work on
>> modifying the packages that will specifically benefit instead of making
>> every other package maintainer in Debian add a new target that really
>> isn't meaningful for their package?

> Already 25% of all packages do have the targets and I assume a lot
> more than 1% to benefit.

I'd be curious to see your reasoning there.

All of my packages have build-arch and build-indep targets.  None of them
benefit from them at all.  I expect many other people have similarly added
the targets just because, or have the targets provided by a build system
such as CDBS, even though they don't benefit.

> Weigh that against the cost, adding a % to the build target or adding
> 'build-%: build', for the packages without meaningful distinction.

As many people have previously pointed out, that's not the real cost.

I really don't see any justification for forcing all packages to change
when we have a proposed solution that lets only the packages that benefit
change.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Can we require build-arch/indep targets for lenny?

[Goswin von Brederlow]

Russ Allbery <[EMAIL PROTECTED]> writes:

> Goswin von Brederlow <[EMAIL PROTECTED]> writes:
>> Russ Allbery <[EMAIL PROTECTED]> writes:
>
>>> I really don't think that declaring the majority of packages in Debian
>>> buggy in this fashion is viable, particularly when nearly all packages
>>> in Debian will not benefit from this.  My guess is that something on
>>> the order of 1% of packages have a meaningful distinction between
>>> build-arch and build-indep, if that, but that includes some packages
>>> that benefit a *lot*.  Wouldn't it be better to only have to work on
>>> modifying the packages that will specifically benefit instead of making
>>> every other package maintainer in Debian add a new target that really
>>> isn't meaningful for their package?
>
>> Already 25% of all packages do have the targets and I assume a lot
>> more than 1% to benefit.
>
> I'd be curious to see your reasoning there.
>
> All of my packages have build-arch and build-indep targets.  None of them
> benefit from them at all.  I expect many other people have similarly added
> the targets just because, or have the targets provided by a build system
> such as CDBS, even though they don't benefit.

For example how many sources have a tex file that they run through
latex for a -doc package?

grep-dctrl -F Build-Depends tetex 
ftp.de.debian.org_debian_dists_sid_main_source_Sources -s Package | wc -l 
112

That alone is already 1%.

There might be more involved than just adding the build-arch target to
actualy benefit from it but I see a lot more potential than 1%.

>> Weigh that against the cost, adding a % to the build target or adding
>> 'build-%: build', for the packages without meaningful distinction.
>
> As many people have previously pointed out, that's not the real cost.

There is nothing else costing anything because there is nothing else
to do when the package has no meaningful distinction. You might
disagree what the cost of it is but that is the only thing causing the
cost.

> I really don't see any justification for forcing all packages to change
> when we have a proposed solution that lets only the packages that benefit
> change.

And I don't see the need to invent some field when it is not needed.

Anyway, as long as it gets solved I'm happy. But please people, solve
it.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Can we require build-arch/indep targets for lenny?

[Russ Allbery]

Goswin von Brederlow <[EMAIL PROTECTED]> writes:
> Russ Allbery <[EMAIL PROTECTED]> writes:

>> All of my packages have build-arch and build-indep targets.  None of
>> them benefit from them at all.  I expect many other people have
>> similarly added the targets just because, or have the targets provided
>> by a build system such as CDBS, even though they don't benefit.

> For example how many sources have a tex file that they run through
> latex for a -doc package?

> grep-dctrl -F Build-Depends tetex 
> ftp.de.debian.org_debian_dists_sid_main_source_Sources -s Package | wc -l 
> 112

> That alone is already 1%.

> There might be more involved than just adding the build-arch target to
> actualy benefit from it but I see a lot more potential than 1%.

Oh, you mean "would possibly benefit if the maintainer restructures the
rules accordingly" as opposed to packages which could take advantage of it
right now.  Yeah, there are more of those, but I expect few will bother.
I have packages that generate arch-independent files, but they're done as
part of the upstream build process, and breaking apart real build-arch and
build-indep targets and patching the upstream build system accordingly
isn't worth the bother for the tiny amount of time saved.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]