On Sat, Sep 02, 2017 at 06:48:11PM +0200, Rafael Laboissière wrote: > Olá Antonio, > > Thank you for your thorough reply. I am sending this message with the > Debian Octave Group (DOG) mailing list in Cc. Please, keep it in the > subsequent replies. > > * Antonio Terceiro <terceiro@debian.org> [2017-09-02 12:43]: > > > On Fri, Sep 01, 2017 at 09:49:26PM +0200, Rafael Laboissière wrote: > > > diff --git a/support/octave/detect b/support/octave/detect new file > > > mode 100755 index 0000000..60b3d19 --- /dev/null +++ > > > b/support/octave/detect @@ -0,0 +1,12 @@ +#!/bin/sh + +### Select > > > only the packages from Octave-Forge that are maintained through +### > > > the octave-pkg-dev tools. This restriction is necessary because the > > > +### autopkgtest command relies on the infrastructure provided by > > > the +### octave-pkg-dev package, namely the use of a CDBS-based > > > debian/rules +### that accepts the 'check-pkg' target. + +test -f > > > debian/rules \ + && grep --quiet '^include > > > /usr/share/cdbs/1/class/octave-pkg.mk$' debian/rules \ + && > > > grep-dctrl --quiet -F Source -r '^octave-.*$' debian/control \ + > > > && test -f DESCRIPTION > > > > I don't like how this works at the moment. These tests should be for the > > installed package, and should not rely on the build infrastructure. > > The tests do actually test the *_installed_* package and *_not_* the files > in the source tree. It needs the build infrastructure because it relies on > calling debian/rules with the 'check-pkg' argument, which is provided by the > octave-pkg.mk, which is present in the octave-pkg-dev package. > > > > diff --git a/support/octave/generate b/support/octave/generate new > > > file mode 100755 index 0000000..d53257d --- /dev/null +++ > > > b/support/octave/generate @@ -0,0 +1,7 @@ +#!/bin/sh + +cat <<EOF > > > +Test-Command: debian/rules check-pkg +Depends: @, octave-pkg-dev > > > (>= 1.5.0) +Restrictions: allow-stderr +EOF > > > > Making the tests depend on octave-pkg-dev will pull a lot of build > > infrastructure into the test environment, such as debhelper, > > build-essential. That is a problem because it can mask missing > > dependencies (i.e. your package works on the test environment even > > though it wouldn't work for a regular user installing it). > > Could you please develop on that? Why would there be differences in > environments, as regards the support I am proposing? autopkgtest was conceived as a way to test packages in an environment close to what _users_ get when they install those packages on their systems. Since users usually won't have development tools around, running tests with development tools around does not reflect that. > > Look for example how it is done for Perl: the test shared test helper > > code is in a specific package (pkg-perl-autopkgtest) with minimal > > dependencies, so the tests can be executed without any development tools > > installed. > > Yes, I understand this, but in the case of the packages maintained by the > DOG, we have already the infrastructure for running the tests at build time > (and, yes, it depends on building infrastructure, like cdbs). Our goal was > to use the identical infrastructure for running unit tests at building time > and at Debian CI time. > > I could write a pkg-octave-autopkgtest, but I am really not willing to do > it, because it would represent an extra maintenance burden. You don't need to create a new source package, you can just move the testing part to a new binary from the same source as octave-pkg-dev, and make the binary package octave-pkg-dev depend on it, then make the code that calls the tests during the build and the autopkgtest control file use the same test helper tool, perhaps with different options. for example gem2deb-test-runner, the Ruby test helper, is called with the `--autopkgtest` option under autopkgtest, what makes it ensure that no code from the source package will be loaded . > > > I have two questions: > > > > > > a) Should I just include the octave section into examples.md or > > > should I run examples.sh to generate it? > > > > it's better to run `make update-examples` to do that for you. > > Yes, but this changes the entries in example.md for go and python. I > accidentally committed this change: > > https://anonscm.debian.org/cgit/collab-maint/autodep8.git/commit/?h=octave&id=409fb69056193957bdc804a9f5d2a0ba49e90aee > > but I revert it later, because I am not sure what to do in this case. the point of generating the examples automatically is exactly to make sure that the examples contain _exactly_ what autodep8 would generate in reality, so you didn't need to revert those. > > > b) I am unsure what should go into test/octave_test.sh file. Could > > > you please give me some hints here, please? > > > > it should contain "unit"-style tests for your language, i.e. tests that > > produce sample minimal source packages that should be handled by your > > support and then checks if the package is correcly detected, and that he > > test control content generated is the correct one. There are several > > examples in the tests for languages that are already supported. > > It took me some time to figure out, but I came out with (what I think are) > the appropriate unit tests: > > https://anonscm.debian.org/cgit/collab-maint/autodep8.git/commit/?h=octave&id=98f0332758023a2d61e5099cc697c6ba12b62dce yes, those tests makes sense. However I would still like to not depend on the build infrastructure for running the tests.
Attachment:
signature.asc
Description: PGP signature