On Sat, 13 Oct 2007, Frank Lichtenheld wrote:
1) Build-Options field
As pointed out this doesn't scale very well and there is no real way to
make it default behaviour one day. This would be the way to go though if
it only needs to be specified for few packages (either because we think
that
On Mon, Jul 02, 2007 at 09:26:23PM -0700, Steve Langasek wrote:
Attached is a patch to dpkg which implements a check for a 'build-arch'
target using 'make -f debian/rules -qn build-arch'.
Is there actually a defined semantic for make -qn ? The make info manual
states:
It is an error to use
Wouter Verhelst [EMAIL PROTECTED] writes:
On Fri, Jun 29, 2007 at 11:11:04PM +0200, Bill Allombert wrote:
One of the issue is that tools like sbuild and pbuilder which want to
take advantage of the Build-Depends-Indep split needs to know whether
dpkg-buildpackage will call debian/rules build
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
Wouter Verhelst [EMAIL PROTECTED] writes:
On Mon, Jul 02, 2007 at 03:28:05PM +0200, Simon Richter wrote:
Running debian-rules can always have side effects and can actively
rely on them so a --has-target can not be implemented cleanly in
make.
I am proposing hooking into the logic that
On 02/07/07 at 21:26 -0700, Steve Langasek wrote:
Lucas has agreed to doing a full archive rebuild with a modified dpkg-dev,
for comparison with the previous test. A dpkg-dev binary including this
change can be found at
http://people.debian.org/~vorlon/dpkg-dev_1.14.4-0.1_all.deb.
Hi,
Here
On Tue, Jul 03, 2007 at 06:07:54PM +0100, Ian Jackson wrote:
Steve Langasek writes (Re: Bug#229357: Can we require build-arch/indep
targets for lenny?):
Attached is a patch to dpkg which implements a check for a 'build-arch'
target using 'make -f debian/rules -qn build-arch'.
Why are we
On Tue, Jul 03, 2007 at 10:01:47AM -0700, Steve Langasek wrote:
On Tue, Jul 03, 2007 at 09:54:03AM +0200, Adam Borowski wrote:
So, an idea: what about checking make -f /dev/null blah 2/dev/null first,
for some portability?
What 'blah' are you planning to use that's guaranteed to not have
On Fri, Jun 29, 2007 at 11:11:04PM +0200, Bill Allombert wrote:
One of the issue is that tools like sbuild and pbuilder which want to
take advantage of the Build-Depends-Indep split needs to know whether
dpkg-buildpackage will call debian/rules build or build-arch.
It needs to know no such
On Mon, Jul 02, 2007 at 03:28:05PM +0200, Simon Richter wrote:
Running debian-rules can always have side effects and can actively
rely on them so a --has-target can not be implemented cleanly in
make.
I am proposing hooking into the logic that ultimately decides that
there is no such target
Hi,
Andreas Metzler wrote:
---
Somehow make dpkg-buildpackage -B make use of the build-arch target
if present. Either by detecting it automatically or by something like
#229357.
---
The entire issue circles around not being able to reliably detect
whether the target
Simon Richter [EMAIL PROTECTED] writes:
Hi,
Andreas Metzler wrote:
---
Somehow make dpkg-buildpackage -B make use of the build-arch target
if present. Either by detecting it automatically or by something like
#229357.
---
The entire issue circles around not
Hello,
Goswin von Brederlow wrote:
The seconds part requires that tools like sbuild and pbuilder know
beforehand if build or build-arch will be used.
For packages that do not implement build-arch, it is acceptable to call
the build target with only B-D installed, because that is the way the
On Sat, Jun 30, 2007 at 09:40:29AM +0200, Andreas Metzler wrote:
I think that is just wrong. sbuild should not need to know anything
about dpkg-buildpackage's internals and there is no need for change
here. The currently used and proven interface is:
1. install Build-Depends for running
Bill Allombert wrote:
On Sat, Jun 30, 2007 at 09:40:29AM +0200, Andreas Metzler wrote:
I think that is just wrong. sbuild should not need to know anything
about dpkg-buildpackage's internals and there is no need for change
here. The currently used and proven interface is:
1. install
In article [EMAIL PROTECTED] (gmane.linux.debian.devel.general) you wrote:
On Fri, Jun 29, 2007 at 12:41:04AM +0300, Guillem Jover wrote:
[...]
I've been pondering on what's the cleanest way to fix it for some time,
and I tend to agree with Steve about using the make options to test
for the
On Fri, Jun 29, 2007 at 12:41:04AM +0300, Guillem Jover wrote:
Obviously the dpkg developers are rather busy at the moment. I think
that the right thing to do is to offer to NMU.
Errr, what's the rush now to get this fixed? It's something that has
been there like forever, the bug report
Hi,
On Tue, 2007-06-26 at 14:33:26 +0100, Ian Jackson wrote:
Bill Allombert writes (Re: Can we require build-arch/indep targets for
lenny?):
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
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
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,
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
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.
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
23 matches
Mail list logo
