Re: Test suites after build and Build-Depends.
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 make sense during generation of .dsc and .changes files. This also means that it won't be possible anymore to override the Format field output by dpkg-genchanges. 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, however the source package can't pass additional option to the dpkg-source call made by dpkg-buildpackage (so it never worked as Charles expected it to work, and furthermore the dpkg-source call happens very early in the build process which means the substvars content for this call would have to be fixed or generated in the clean rule) - dpgk-genchanges has very few content that is copied straight from debian/control and the substvars support only ever allowed to change some fields like the Format version (which doesn't make any sense) On Sat, 31 Jan 2009, Charles Plessy wrote: I am not sure I understand. From reading the man page of dpkg-source, it seems to me that: - The 'control' file is used to generate the .dsc file. - The location of the 'control' file is debian/control by default, but this can be changed with the -c option. I have not found evidence in the documentation nor in the source that the building of the .dsc file is a two-step process as you describe. aqwa『~』$ grep -A1 -B1 dsc /usr/bin/dpkg-source Grepping dpkg-source doesn't mean much nowadays, most of the code is in the modules Dpkg::Source::* so not in a single file. I still do not understand what makes it nonsense to use substvars for the generation of the .dsc and .changes file. I hope my answer clarifies the situation. Given that it has not been used in 14 years, and that we had no wishlist bug in that direction, it seems pretty clear that it's useless and that there are other better ways to achieve similar functionnality. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Test suites after build and Build-Depends.
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 it could be, right? (question to the buildd / sbuild gurus) 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 debian/control to check that the build-deps are satisfied in addition. This difference of treatment between binary and source stanzas has always puzzled me, but I'm not sure whether there is some deep technical reason for that, or rather is just that the current buildd implementations don't do that. I always thought that there was a rather simpler practical reason: substvars don't exist before a build starts, which is the point at which we need to install the build-deps. 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 Description: Digital signature
Re: Test suites after build and Build-Depends.
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 debian/control to check that the build-deps are satisfied in addition. Oh, thank you. I was only looking at dpkg-buildpackage. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Test suites after build and Build-Depends.
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 used in 14 years, and that we had no wishlist bug in that direction, it seems pretty clear that it's useless and that there are other better ways to achieve similar functionnality. Le Sat, Jan 31, 2009 at 12:10:18PM +, Roger Leigh a écrit : 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 debian/control to check that the build-deps are satisfied in addition. Thank you all for your answers, from my biologist point of view, I find interesting to observe how an unused function progressively becomes impracticable as the whole system evolves without pressure to stay compatible with it :) Helper tools such as mk-build-dep have not been mentionned in this thread, but would also break with packages containing a substvar in debian/control. I can try prepare a patch for the Policy if you are interested. Have a nice Sunday, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Test suites after build and Build-Depends.
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 Policy. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Test suites after build and Build-Depends.
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, such as $(depends:libfoo-bar-perl} for Foo::Bar. It seems that it is trivial to pass through dh_gencontrol. Substvars don't work for Build-Depends, I'm afraid. Well, according to the Policy sections 5.2 and 4.10, it (should ? must?) work. In reality, it is an endangered mechanism, as it was deprecated in January 2008. Would it be possible to un-deprecate it? If there is some programmation needed, would a patch be welcome? Then a second problem is that, whatever dpkg-source does, there is always a parser that is ran before and that will complain against the substvar. But it should be easy to desensitize it to substvars, which would restore compliance with our Policy. Have a nice day -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Test suites after build and Build-Depends.
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 to accompany the upload, and by dpkg-source when it creates the .dsc source control file as part of a source archive. Many fields are permitted to span multiple lines in debian/control but not in any other control file. These tools are responsible for removing the line breaks from such fields when using fields from debian/control to generate other control files. The fields here may contain variable references - their values will be substituted by dpkg-gencontrol, dpkg-genchanges or dpkg-source when they generate output control files. See Variable substitutions: debian/substvars, Section 4.10 for details. 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, my understanding is that it's not read from that file for package builds. Build dependency information is read directly from debian/control and hence cannot get the benefit of any pre-processing of debian/control. See dpkg-source(1) under the description of the -c option. In reality, it is an endangered mechanism, as it was deprecated in January 2008. I'm not sure what you're referring to here. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Test suites after build and Build-Depends.
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 difference of treatment between binary and source stanzas has
always puzzled me, but I'm not sure whether there is some deep
technical reason for that, or rather is just that the current buildd
implementations don't do that.
If there is no profound reason, it looks like a good candidate to be
uniformed, doesn't it?
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: Test suites after build and Build-Depends.
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 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 make sense during generation of .dsc and .changes files. This also means that it won't be possible anymore to override the Format field output by dpkg-genchanges. Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Test suites after build and Build-Depends.
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 do not make sense during generation of .dsc and .changes files. This also means that it won't be possible anymore to override the Format field output by dpkg-genchanges. Ah! I didn't know about that. That makes a lot of sense, though, given that the build doesn't look at the *.dsc file anyway. I don't think I've ever seen a package that used substvars there, except for attempts to use it for Build-Depends. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Test suites after build and Build-Depends.
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, my understanding is that it's not read from that file for
package builds. Build dependency information is read directly from
debian/control and hence cannot get the benefit of any pre-processing of
debian/control. See dpkg-source(1) under the description of the -c
option.
Hi Russ,
I am not sure I understand. From reading the man page of dpkg-source, it seems
to me that:
- The 'control' file is used to generate the .dsc file.
- The location of the 'control' file is debian/control by default, but this
can be changed with the -c option.
I have not found evidence in the documentation nor in the source that the
building of the .dsc file is a two-step process as you describe.
aqwa『~』$ grep -A1 -B1 dsc /usr/bin/dpkg-source
# Write the .dsc
my $dscname = $srcpkg-get_basename(1) . .dsc;
info(_g(building %s in %s), $sourcepackage, $dscname);
$substvars-parse($varlistfile) if $varlistfile -e $varlistfile;
$srcpkg-write_dsc(filename = $dscname,
remove = \%remove,
--
unless (scalar(@ARGV)) {
usageerr(_g(-x needs at least one argument, the .dsc));
}
--
}
my $dsc = shift(@ARGV);
if (-d $dsc) {
usageerr(_g(-x needs the .dsc file as first argument, not a
directory));
}
--
# Create the object that does everything
my $srcpkg = Dpkg::Source::Package-new(filename = $dsc,
options = \%options);
--
} else {
warning(_g(extracting unsigned source package (%s)), $dsc);
}
--
Commands:
-x filename.dsc [output-dir]
extract source package.
--
-Tvarlistfile read variables here, not debian/substvars.
-Dfield=valueoverride or add a .dsc field and value.
-Ufieldremove a field.
I still do not understand what makes it nonsense to use substvars for the
generation of the .dsc and .changes file.
Have a nice day,
--
Charles Plessy
Tsurumi, Kanagawa, Japan
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Test suites after build and Build-Depends.
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 information is copied into the *.dsc file, my understanding is that it's not read from that file for package builds. Build dependency information is read directly from debian/control and hence cannot get the benefit of any pre-processing of debian/control. See dpkg-source(1) under the description of the -c option. I am not sure I understand. From reading the man page of dpkg-source, it seems to me that: - The 'control' file is used to generate the .dsc file. - The location of the 'control' file is debian/control by default, but this can be changed with the -c option. I have not found evidence in the documentation nor in the source that the building of the .dsc file is a two-step process as you describe. I think you misunderstood what I meant. You are correct that substvars are used in generating the .dsc file. What I was pointing out is that the .dsc file isn't used for anything related to the build, so this doesn't help you. The build of the package ignores the .dsc file and uses debian/control directly. I still do not understand what makes it nonsense to use substvars for the generation of the .dsc and .changes file. It isn't. It just doesn't help with the problem that you're trying to solve. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Test suites after build and Build-Depends.
* 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 this in my packages with a dpkg substvar, such as $(depends:libfoo-bar-perl} for Foo::Bar. It seems that it is trivial to pass through dh_gencontrol. Substvars don't work for Build-Depends, I'm afraid. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Excuse me for thinking a banana-eating contest was about eating a banana! -- Paris Geller -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Test suites after build and Build-Depends.
* 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 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 set twice. My point is: There's nothing mandatory about having the binary stanzas in debian/control contain correct information at the beginning of the build. I don't think nobody is suggesting inferring Build-Dependencies from Depends field. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Excuse me for thinking a banana-eating contest was about eating a banana! -- Paris Geller -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Test suites after build and Build-Depends.
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 set twice. Hi Adeodato and everybody, I do not know who is unhappy; for me, it is more like it is itchy :) 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, such as $(depends:libfoo-bar-perl} for Foo::Bar. It seems that it is trivial to pass through dh_gencontrol. Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Test suites after build and Build-Depends.
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 Charles. What I think he meant is that once 'notest' is widespread enough, its natural evolution would be a way to distinguish dependencies which belong to tests. What is the real goal of adding Build-Depends-Test: ? This wouldn't help the buildds, as they will install the test build-deps anyway (running the test suite on obscure arches is a really good idea, and often allows to find bugs in dependencies). This wouldn't really help the maintainer either. The download time of build-depends can be easily reduced by using a caching proxy (approx is really easy to setup). The installation time of build-depends only used for tests could be a problem, sure, but you should change your process if you suffer from it. For example, I usually do most of the packaging work in an unclean chroot, and use a clean chroot only for the final build. So dependencies are only installed twice. The goals of nocheck are different, and more useful, are bypassing the test suite allows faster builds in all cases. -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Test suites after build and Build-Depends.
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 faster builds in all cases.
The goals of Build-Depends-Test are the same of nocheck: faster
overall build time if you don't care about the test suite. In a sense,
nocheck can be complete only with Build-Depends-Test.
Then you can ask in which scenario you might want to skip test suite
to build faster, ... and I don't think buildds match that scenario.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: Test suites after build and Build-Depends.
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: faster overall build time if you don't care about the test suite. In a sense, nocheck can be complete only with Build-Depends-Test. Then you can ask in which scenario you might want to skip test suite to build faster, ... and I don't think buildds match that scenario. nocheck is not only to reduce build-time but also to allow easier cross-compilation where a cross-compiled test-suite can't run at all on the build machine. Thus I don't think that the argument presented holds. The creation of nocheck doesn't imply that we have to go further and create Build-Depends-Test for completing any initial goal. For me it's useless complexity at this point. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Test suites after build and Build-Depends.
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 packages enough? They usually
duplicate the run-time dependencies in B-D-I for the tests and often
add some extra libtest-foo-perl modules. For the build usually
perl{,-modules} would be enough.
(Note that I'm not conviced of the value of a new Build-Depends-Test
field, I just wanted to provide an additional data point.)
Cheers,
gregor
--
.''`. Home: http://info.comodo.priv.at/{,blog/} / GPG Key ID: 0x00F3CFE4
: :' : Debian GNU/Linux user, admin, developer - http://www.debian.org/
`. `' Member of VIBE!AT, SPI Inc., fellow of FSFE | http://got.to/quote/
`-NP: Bob Dylan: Summer Days
signature.asc
Description: Digital signature
Re: Test suites after build and Build-Depends.
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 I'm not convinced it is the case. 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 *duplicate* these? Normaly, dependencies in B-D needn't appear in B-D-I. Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Test suites after build and Build-Depends.
* 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 packages with enough test-only dependencies, which I'm not convinced it is the case. 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 *duplicate* these? Normaly, dependencies in B-D needn't appear in B-D-I. They duplicate the Depends line into B-D-I. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Test suites after build and Build-Depends.
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 *duplicate* these? Normaly, dependencies in B-D needn't appear in B-D-I. Run-time dependencies, hence bin pkg Depends field, not B-D. Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Test suites after build and Build-Depends.
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 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 packages enough? They usually duplicate the run-time dependencies in B-D-I for the tests OT, but why do they need to *duplicate* these? Normaly, dependencies in B-D needn't appear in B-D-I. They duplicate the Depends line into B-D-I. OTOH, we can't just say let's change policy so that both depends and build-depends are required to build the package. It's a chicken-and-egg problem: binary deps are not known until you build the binary package... -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Test suites after build and Build-Depends.
* 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 net.com.org.es Debian Developer adeodato at debian.org Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian W. Kernighan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Test suites after build and Build-Depends.
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? please explain. The Depends: could be created/modified during the build (see packages using control.in for example). If you want to parse the binary stanzas in debian/control to determine the depends before building, then it's a fragile approach. -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Test suites after build and Build-Depends.
* 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 the case with many of our interpreted languages. uh? please explain. Ok. You package libfoo-ruby. For version 1.0-1, you write in debian/control: Source: ruby-foo Build-Depends: debhelper, ruby Package: libfoo-ruby1.8 Depends: ruby (= 1.8), libbar-ruby1.8, libmoo-ruby1.8, libquack-ruby1.8 ... Now, version 1.5 comes along, and it adds a testsuite, which is run using the libtest-me-harder-ruby1.8 package. So you run the test suite from debian/rules and update debian/control for 1.5-1 like this: Source: ruby-foo Build-Depends: debhelper, ruby, libtest-me-harder-ruby1.8 Package: libfoo-ruby1.8 Depends: ruby (= 1.8), libbar-ruby1.8, libmoo-ruby1.8, libquack-ruby1.8 ... Except that it does not work, because of course the test suite wants to run the program, which in turns wants to require 'bar', 'moo', and 'quack'. So your debian/control ends ups like: Source: ruby-foo Build-Depends: debhelper, ruby, libtest-me-harder-ruby1.8, libbar-ruby1.8, libmoo-ruby1.8, libquack-ruby1.8 Package: libfoo-ruby1.8 Depends: ruby (= 1.8), libbar-ruby1.8, libmoo-ruby1.8, libquack-ruby1.8 ... Which makes Charles Plessy unhappy, and which isn't really solvable without something akin to control.in, either from debian/rules or, futuristically, dpkg-dev toolchain. And then, Build-Depends-Test is something different altogether. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org As an adolescent I aspired to lasting fame, I craved factual certainty, and I thirsted for a meaningful vision of human life -- so I became a scientist. This is like becoming an archbishop so you can meet girls. -- Matt Cartmill -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Test suites after build and Build-Depends.
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 binary package... That is simply not true, and not the case with many of our interpreted languages. uh? please explain. Ok. You package libfoo-ruby. For version 1.0-1, you write in debian/control: Source: ruby-foo Build-Depends: debhelper, ruby Package: libfoo-ruby1.8 Depends: ruby (= 1.8), libbar-ruby1.8, libmoo-ruby1.8, libquack-ruby1.8 ... Now, version 1.5 comes along, and it adds a testsuite, which is run using the libtest-me-harder-ruby1.8 package. So you run the test suite from debian/rules and update debian/control for 1.5-1 like this: Source: ruby-foo Build-Depends: debhelper, ruby, libtest-me-harder-ruby1.8 Package: libfoo-ruby1.8 Depends: ruby (= 1.8), libbar-ruby1.8, libmoo-ruby1.8, libquack-ruby1.8 ... Except that it does not work, because of course the test suite wants to run the program, which in turns wants to require 'bar', 'moo', and 'quack'. So your debian/control ends ups like: Source: ruby-foo Build-Depends: debhelper, ruby, libtest-me-harder-ruby1.8, libbar-ruby1.8, libmoo-ruby1.8, libquack-ruby1.8 Package: libfoo-ruby1.8 Depends: ruby (= 1.8), libbar-ruby1.8, libmoo-ruby1.8, libquack-ruby1.8 ... 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. With which I agree, of course. My point is: There's nothing mandatory about having the binary stanzas in debian/control contain correct information at the beginning of the build. -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Test suites after build and Build-Depends.
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 address
your issue.
Thanks for the pointer.
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 Charles. What I think he meant is
that once 'notest' is widespread enough, its natural evolution would
be a way to distinguish dependencies which belong to tests.
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. If
they are rare enough, debian/control.in + README.Debian-source is the
way to go.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: Test suites after build and Build-Depends.
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 packaging some perl modules: * libfile-find-rule-perl-perl needs libtest-minimumversion-perl to run all its tests and libtest-minimumversion-perl depends on libfile-find-rule-perl-perl. To avoid this circular dependency, libfile-find-rule-perl-perl build-depends on libtest-minimumversion-perl (= 0.007) | perl and some tests are skipped if libtest-minimumversion-perl is not installed. * I did the same for the libparse-cpan-meta-perl package: libparse-cpan-meta-perl build depends on: ... libtest-cpan-meta-perl (= 0.07) | perl, libperl-minimumversion-perl (= 0.007) | perl, because libtest-cpan-meta-perl depends AND build-depends on libparse-cpan-meta-perl and libperl-minimumversion-perl build-depends on libtest-cpan-meta-perl I found that using libXXX-perl | perl still allows the package to be build if the libXXX-perl is not available (with less tests in these cases). I do not know if there are some better solutions. Regards, Vincent -- Vincent Danjean GPG key ID 0x9D025E87 vdanj...@debian.org GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87 Unofficial pacakges: http://www-id.imag.fr/~danjean/deb.html#package APT repo: deb http://perso.debian.org/~vdanjean/debian unstable main -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Test suites after build and Build-Depends.
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 this
is not satisfactory, because:
- The build dependancy graph becomes unnecessarily complex when running the
test suite is skipped.
I don't buy this argument, i.e., please expand it.
Build-Depends determines what is needed to completely perform the
process of turning a Debian source package into a set of Debian binary
packages. If that includes running tests, the test dependencies should
be mentioned there. If you are arguing that Build-Depends is too
coarse grained, and it might need a more precise splitting, according
to which debian/rules target build-dependencies are for, I might
concur. Still, the benefits of doing the needed split are not clear to
me.
- Information is duplicated between Build-Depends: and the binary packages's
Depends: field.
Uh? Why? In general test suite dependencies are not the same as binary
package dependencies, they might be:
- larger: due to the need of test framework which are not needed at
runtime
- smaller: due to part of the source code for which there are no tests
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: Test suites after build and Build-Depends.
* 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 I pointed out (as I will now) that this mostly affects software written in interpreted languages, since when compiling, the resulting Dependencies are probably already installed. - Information is duplicated between Build-Depends: and the binary packages's Depends: field. If this really, really annoys you, you can always use debian/control.in pin a way that's allowed to be used). Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org «¡Pero si es tan español que debe de tener el cerebro en forma de botijo, con pitorro y todo!» -- Javier Cercas, “La velocidad de la luz” -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Test suites after build and Build-Depends.
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 debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Test suites after build and Build-Depends.
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 modify your debian/control file. One of the interests of those test suits is to be executed automatically by buildd (on arch that you cannot easily test). -- I WILL NOT SELL SCHOOL PROPERTY I WILL NOT SELL SCHOOL PROPERTY I WILL NOT SELL SCHOOL PROPERTY -+- Bart Simpson on chalkboard in episode 7F10 pgpAIGmW8NALJ.pgp Description: PGP signature
Re: Test suites after build and Build-Depends.
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 interests of those test suits is to be executed automatically by buildd (on arch that you cannot easily test). Aha, thanks for the clarification. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Test suites after build and Build-Depends.
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 more things to depend on. In particular, some of the packages I worked on recently provide wrappers for other programs, which can have complex dependancies as well. This is why for instance I end up pulling mysql-common when cowbuilding python-biopython (I miserably failed to arrange the test target correctly for sbuild). This spagetthi effect is what I thought about when I wrote unnecessarly complex: 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. 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. Maybe I overvaluated this issue. In the context of a 'notest' option, listing the packages on which the source package build-depends only for the tests would make sense, so that their installation can be skipped as well. Probably we can postpone the discussion until there are serious attempts to push 'notest' to our build toold and the Policy. In the packages I prepared, I ended up duplicating the binary packages's Depends, Recommends and Suggests (excluding the non-free ones) into the Build-Depends field. Fortunately, we can intercalate comments, so I documented which packages are needed for building and which are needed for testing. As for the most complex packages, keeping these two lists synchronised is error-prone, I will think about a 'control.in' system as Adeodato suggested. Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Test suites after build and Build-Depends.
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 I overvaluated this issue. In the context of a 'notest' option, listing the packages on which the source package build-depends only for the tests would make sense, so that their installation can be skipped as well. There isn't anything about that in the upcoming Policy change. The assumption of the Policy change is that checks would be enabled by default; nocheck is available if for some reason one wants to disable those. The upcoming wording doesn't add a way to distinguish between build dependencies required for the build and ones required for testing. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
