[Pkg-octave-devel] Switch octave-pkg-dev from CDBS into dh

[Rafael Laboissière]

* Sébastien Villemot <sebastien at debian.org> [2017-12-28 10:23]:

> On Thu, Dec 28, 2017 at 08:51:42AM +0100, Rafael Laboissière wrote:
>>
>> As I expected, it was not difficult to adapt the code in octave-pkg-dev for 
>> switching from CDBS into dh.  It is implemented in the Git branch 
>> dh-instead-of-cdbs.  Just for the record, I am attaching below the diff 
>> against master.
>
> Thanks. Note that you forgot to drop the Depends of octave-pkg-dev on cdbs.

This is on purpose, because there is a call to licensecheck2dep5 in 
make-octave-forge-debpkg.  Should I downgrade the Depends:cdbs to 
Recommends:cdbs?

> Also you probably want to add an (empty) override_dh_auto_check, in 
> case there is a top-level makefile with a "check" or "test" target.

Well spotted.  It is done.

> Also, if we upload the octave-pkg-dev now, we need to also upload all Forge 
> packages, because otherwise they will become RC-buggy (FTBFS).

I will to it, as I mentioned previously.  Actually, it is almost done in 
my local copies of the repositories.  I am fixing the corner cases and 
looking at the issues that you raise below.

> I am also wondering how we should override some targets with this new setup. 
> Many Forge packages have a "clean::" rule, [snip]

We should use debian/clean for those.

> [snip] or some "install/FOO::" rule (see for example octave-optim). It 
> is not immediately obvious to me how to deal with these (without 
> knowing the internals of octave-pkg-dev).
>
> More fundamentally, the solution that you have come up with is quite clever, 
> because it needs only minimal changes to the existing setup, but in a sense it 
> is not very dh-ish (and it looks very cdbs-ish). The typical solution to extend 
> dh for a given class of package is to write some Perl code that integrates at a 
> deeper level with debhelper (see the myriad of dh-*, for example dh-ocaml which 
> is rather simple and probably not too far from what we would need). Note that, 
> with this setup, it is much simpler to override targets from debian/rules, 
> because the helper does not hijack existing targets, but adds new ones (see for 
> example /usr/share/perl5/Debian/Debhelper/Sequence/ocaml.pm).
>
> So another plan would be to create a new binary package dh-octave (from the 
> octave-pkg-dev source), containing something similar to, say, dh-ocaml. Then we 
> could do the transition gradually, because the old cdbs-based octave-pkg-dev 
> would still be around (and could be retired when the transition is over).

Ok, this is a sensible plan for the future.  Let us start by getting rid 
of the build-dependency on cdbs with the upcoming 2.0.0 version and, 
later, we can discuss about a new design, which will imply a more 
substantial refactoring of the code in octave-pkg-dev.

> I am aware that this is much more work than what you did, and I am not at this 
> point volunteering for doing this, so I’m not saying that this is the right 
> solution and that what you did should be discarded. But at the very least, if 
> we keep your solution, we need to solve the override problem I mentioned above.

You are right, there are packages with cdbs-dependent targets like 
install/pkg::, build/pkg::, and clean::.  We will look at this very 
real issue.

Rafael