On Fri, 30 Jan 2009, Adam D. Barratt wrote:
I'd guess Charles meant the following addition to
README.feature-removal-schedule, from the dpkg source package:
What: substvars support in dpkg-source and dpkg-genchanges
Status: deprecated
When: lenny+1
Warning: program
Why:
substvars do not
On Fri, Jan 30, 2009 at 06:50:05PM +0100, Stefano Zacchiroli wrote:
On Fri, Jan 30, 2009 at 09:00:46AM -0800, Russ Allbery wrote:
However, while build dependency information is copied into the *.dsc
file, my understanding is that it's not read from that file for
package builds.
... while
Roger Leigh rle...@codelibre.net writes:
The .dsc file is exactly where the information is read from. See
fetch_source_files() in Sbuild/Build.pm. This is for installing
and removing build-dependencies and build-conflicts, respectively.
Note that dpkg-buildpackage and other tools read
Le Sat, Jan 31, 2009 at 10:15:15AM +0100, Raphael Hertzog a écrit :
Note that this decision has been taken because:
- dpkg-source has never used debian/substvars as input and did nothing
unless you gave the -T option
I hope my answer clarifies the situation. Given that it has not been
Charles Plessy ple...@debian.org writes:
I can try prepare a patch for the Policy if you are interested.
That would be great here. The current text doesn't reflect reality, so
unless we're going to change reality (for which there doesn't appear to be
much of a consensus), we should change
Hi again,
At the beginning I thought that skipping the depandancy needed for build-time
tests was a logical extension, but now we all agree that it is useless. For
the
factorisation of the package list between Depends and Build-Depends, I will
solve this in my packages with a dpkg substvar,
Charles Plessy ple...@debian.org writes:
Well, according to the Policy sections 5.2 and 4.10, it (should ? must?)
work.
Policy 5.2:
These fields are used by dpkg-gencontrol to generate control files for
binary packages (see below), by dpkg-genchanges to generate the
.changes file
On Fri, Jan 30, 2009 at 09:00:46AM -0800, Russ Allbery wrote:
However, while build dependency information is copied into the *.dsc
file, my understanding is that it's not read from that file for
package builds.
... while it could be, right?
(question to the buildd / sbuild gurus)
This
On Fri, 2009-01-30 at 09:00 -0800, Russ Allbery wrote:
Charles Plessy ple...@debian.org writes:
In reality, it is an endangered mechanism, as it was deprecated in
January 2008.
I'm not sure what you're referring to here.
I'd guess Charles meant the following addition to
Adam D. Barratt a...@adam-barratt.org.uk writes:
I'd guess Charles meant the following addition to
README.feature-removal-schedule, from the dpkg source package:
What: substvars support in dpkg-source and dpkg-genchanges
Status: deprecated
When: lenny+1
Warning: program
Why:
substvars
Le Fri, Jan 30, 2009 at 09:00:46AM -0800, Russ Allbery a écrit :
What this is saying is that substvars will be expanded by those three
programs when generating the *.dsc, the *.changes, and the binary control
files. However, while build dependency information is copied into the
*.dsc file,
Charles Plessy ple...@debian.org writes:
Le Fri, Jan 30, 2009 at 09:00:46AM -0800, Russ Allbery a écrit :
What this is saying is that substvars will be expanded by those three
programs when generating the *.dsc, the *.changes, and the binary
control files. However, while build dependency
* Charles Plessy [Wed, 28 Jan 2009 14:39:59 +0900]:
At the beginning I thought that skipping the depandancy needed for build-time
tests was a logical extension, but now we all agree that it is useless. For
the
factorisation of the package list between Depends and Build-Depends, I will
solve
* Lucas Nussbaum [Mon, 26 Jan 2009 23:40:24 +0100]:
OK. Your point is:
In most cases, the binary stanzas in debian/control will contain the
correct set of binary dependencies at the beginning of the build.
No, not really. My point is: *some* of the people whose packages have
binary
Le Tue, Jan 27, 2009 at 09:53:00AM +0100, Adeodato Simó a écrit :
No, not really. My point is: *some* of the people whose packages have
binary stanzas in debian/control which contain the correct set of binary
dependencies at the beginning of the build, are unhappy about having to
write said
On 26/01/09 at 08:44 +0100, Stefano Zacchiroli wrote:
On Fri, Jan 23, 2009 at 09:12:43PM -0800, Russ Allbery wrote:
The upcoming wording doesn't add a way to distinguish between build
dependencies required for the build and ones required for testing.
I think that was already clear to
On Mon, Jan 26, 2009 at 09:59:04AM +0100, Lucas Nussbaum wrote:
What is the real goal of adding Build-Depends-Test: ?
[ Note that I'm not pushing for that, but still, for the sake of the
argument ... ]
The goals of nocheck are different, and more useful, are bypassing
the test suite allows
On Mon, 26 Jan 2009, Stefano Zacchiroli wrote:
On Mon, Jan 26, 2009 at 09:59:04AM +0100, Lucas Nussbaum wrote:
The goals of nocheck are different, and more useful, are bypassing
the test suite allows faster builds in all cases.
The goals of Build-Depends-Test are the same of nocheck:
On Mon, 26 Jan 2009 08:44:01 +0100, Stefano Zacchiroli wrote:
Personally, I'd add as a condition for this to be a reasonable
request, the fact that there should be enough packages with enough
test-only dependencies, which I'm not convinced it is the case.
Are around 1200 arch:any libfoo-perl
On Mon, Jan 26, 2009 at 06:52:00PM +0100, gregor herrmann wrote:
On Mon, 26 Jan 2009 08:44:01 +0100, Stefano Zacchiroli wrote:
Personally, I'd add as a condition for this to be a reasonable
request, the fact that there should be enough packages with enough
test-only dependencies, which
* Mike Hommey [Mon, 26 Jan 2009 19:13:10 +0100]:
On Mon, Jan 26, 2009 at 06:52:00PM +0100, gregor herrmann wrote:
On Mon, 26 Jan 2009 08:44:01 +0100, Stefano Zacchiroli wrote:
Personally, I'd add as a condition for this to be a reasonable
request, the fact that there should be enough
On Mon, Jan 26, 2009 at 19:13, Mike Hommey m...@glandium.org wrote:
On Mon, Jan 26, 2009 at 06:52:00PM +0100, gregor herrmann wrote:
Are around 1200 arch:any libfoo-perl packages enough? They usually
duplicate the run-time dependencies in B-D-I for the tests
OT, but why do they need to
On 26/01/09 at 19:15 +0100, Adeodato Simó wrote:
* Mike Hommey [Mon, 26 Jan 2009 19:13:10 +0100]:
On Mon, Jan 26, 2009 at 06:52:00PM +0100, gregor herrmann wrote:
On Mon, 26 Jan 2009 08:44:01 +0100, Stefano Zacchiroli wrote:
Personally, I'd add as a condition for this to be a
* Lucas Nussbaum [Mon, 26 Jan 2009 19:21:54 +0100]:
It's a chicken-and-egg problem: binary deps are not known until
you build the binary package...
That is simply not true, and not the case with many of our interpreted
languages.
--
Adeodato Simó dato at
On 26/01/09 at 19:26 +0100, Adeodato Simó wrote:
* Lucas Nussbaum [Mon, 26 Jan 2009 19:21:54 +0100]:
It's a chicken-and-egg problem: binary deps are not known until
you build the binary package...
That is simply not true, and not the case with many of our interpreted
languages.
uh?
* Lucas Nussbaum [Mon, 26 Jan 2009 22:51:24 +0100]:
On 26/01/09 at 19:26 +0100, Adeodato Simó wrote:
* Lucas Nussbaum [Mon, 26 Jan 2009 19:21:54 +0100]:
It's a chicken-and-egg problem: binary deps are not known until
you build the binary package...
That is simply not true, and not
On 26/01/09 at 23:08 +0100, Adeodato Simó wrote:
* Lucas Nussbaum [Mon, 26 Jan 2009 22:51:24 +0100]:
On 26/01/09 at 19:26 +0100, Adeodato Simó wrote:
* Lucas Nussbaum [Mon, 26 Jan 2009 19:21:54 +0100]:
It's a chicken-and-egg problem: binary deps are not known until
you build the
On Fri, Jan 23, 2009 at 09:12:43PM -0800, Russ Allbery wrote:
In addition, I thought that the 'notest' build option that was discussed
last year (or the year before?) on this list made it into the Policy,
but I was wrong.
nocheck will be in 3.8.1 (see Bug#416450), but it doesn't really
Charles Plessy wrote:
I felt a bit afraid that in some
situations where some packages are temporarly mutually incompatible, we can
end
up in a situation where the source package that depends on it is not
rebuidable
unless the tests are disabled.
I found this kind of situation when
On Fri, Jan 23, 2009 at 02:53:59PM +0900, Charles Plessy wrote:
I packaged a lot programs that have a test suite, and realised that, in order
to run it after build, the dependancies of the binary package produced must be
present as well. For the moment, I add them in Build-Depends(-Indep), but
* Charles Plessy [Fri, 23 Jan 2009 14:53:59 +0900]:
Dear all,
I packaged a lot programs that have a test suite, and realised that,
in order to run it after build, the dependancies of the binary package
produced must be present as well.
I think you've brought up this in the past already, and
What about providing a test target in debian/rules and hooking into this
automatically with pdebuild. You should be able to run tests from within the
chroot without having to modify your debian/control file.
--
Noah Slater, http://tumbolia.org/nslater
--
To UNSUBSCRIBE, email to
OoO Lors de la soirée naissante du vendredi 23 janvier 2009, vers 18:55,
Noah Slater nsla...@tumbolia.org disait :
What about providing a test target in debian/rules and hooking into this
automatically with pdebuild. You should be able to run tests from within the
chroot without having to
On Fri, Jan 23, 2009 at 08:24:41PM +0100, Vincent Bernat wrote:
What about providing a test target in debian/rules and hooking into this
automatically with pdebuild. You should be able to run tests from within the
chroot without having to modify your debian/control file.
One of the
Dear Stefano, Adeodato and Noah, thank you for your answers.
Indeed, I wrote my previous mail after packaging half a dozen of perl modules,
plus enabling tests in a python package. For compiled programs, the situation
is definitely more simple. However, as Stefano noted, there may be sometimes
Charles Plessy ple...@debian.org writes:
In addition, I thought that the 'notest' build option that was discussed
last year (or the year before?) on this list made it into the Policy,
but I was wrong.
nocheck will be in 3.8.1 (see Bug#416450), but it doesn't really address
your issue.
Maybe
Dear all,
I packaged a lot programs that have a test suite, and realised that, in order
to run it after build, the dependancies of the binary package produced must be
present as well. For the moment, I add them in Build-Depends(-Indep), but this
is not satisfactory, because:
- The build
37 matches
Mail list logo
