[Pkg-octave-devel] Adding Octave support

[Rafael Laboissière]

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 at debian.org> [2017-09-02 12:43]:

> On Fri, Sep 01, 2017 at 09:49:26PM +0200, Rafael Laboissière wrote:
>> Dear autodep8 maintainers,
>>
>> I added preliminary support in autodep8 for the Octave-Forge [1] packages 
>> maintained by the Debian Octave Group [2].  It is in the 'octave' branch of 
>> the Git repository for autodep8.  I put my changes into a branch because I 
>> am not sure about the development policy.  Please tell me whether I can 
>> merge my branch into master.
>
> Thanks for looking into this. Adding support new classes of packages will help 
> us increase the test coverage in Debian, and the overall quality of the 
> distribution.

Indeed, my patch will add autodep8 support for 51 Octave-Forge add-on 
packages, which are currently maintained by the DOG.

> I have looked at the code, and I have a few comments about it. Keep in 
> mind that I am completely clueless about specifics of octave packages, 
> so if I say something that doesn't make sense, please let me know.
>
> I will paste your current changes here so that I can comment:
>
>> 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?

> 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.

>> 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.

>> 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

Rafael