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
Hi,
Frank Lichtenheld schrieb:
3) Autodetection
My approach would be to have the autobuilders use build-arch, and if
that fails within 60 seconds, clean and build.
If build-arch is not implemented, it fails rather quickly, so we use
build and make a note in the build log. Later, one can
On Sat, Sep 29, 2007 at 10:09:19PM +0200, Frank Lichtenheld wrote:
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
On Fri, Oct 12, 2007 at 10:49:13PM +0200, Frank Lichtenheld wrote:
On Sat, Sep 29, 2007 at 10:09:19PM +0200, Frank Lichtenheld wrote:
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
On Fri, Oct 12, 2007 at 02:13:49PM -0700, Steve Langasek wrote:
On Fri, Oct 12, 2007 at 10:49:13PM +0200, Frank Lichtenheld wrote:
No answer? I would like to work on this, but someone would need to
answer my questions about it...
(explicetly sending to vorlon, too, ignoring the M-F-T)
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
Hi,
Ian Jackson wrote:
We want the package to _declare_ whether it supports this new target.
Ideally, we'd want all packages to support the new target, and then turn
that into policy, otherwise we'll end up supporting both for a very long
time.
The proposed -Options field will actually
Hi,
Wouter Verhelst wrote:
$(shell ls temp-target-* rm temp-target-*):
Yes, that's broken, but there are your side effects, and you'll have to
run this code if you want to make your --has-target work.
Yes, that is exactly what I'm proposing. The same thing happens for -q
mode now.
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 Mon, Jul 02, 2007 at 09:26:23PM -0700, Steve Langasek wrote:
I believe the attached patch has the following characteristics:
- Behavior on systems where 'make' is not GNU make is undefined.
Specifically, on such a system dpkg is likely to either conclude that
/all/ packages support
On Tue, Jul 03, 2007 at 09:54:03AM +0200, Adam Borowski wrote:
On Mon, Jul 02, 2007 at 09:26:23PM -0700, Steve Langasek wrote:
I believe the attached patch has the following characteristics:
- Behavior on systems where 'make' is not GNU make is undefined.
Specifically, on such a system
Simon Richter writes (Re: Bug#229357: Can we require build-arch/indep targets
for lenny?):
The entire issue circles around not being able to reliably detect
whether the target is present using a simple script. But who said it has
to be a script?
We want the package to _declare_ whether
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 so resistant to the new debian/control field ? That
doesn't
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, Steve Langasek 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 broken
side-effects in some cases on Debian packages?
How about:
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 Sun, Jul 01, 2007 at 05:22:31PM +0200, 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
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
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
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
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
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])
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.
37 matches
Mail list logo