* Sébastien Villemot <sebastien@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