Re: Debhelper for R packages
Gordon, Andreas,
On 8 September 2016 at 22:37, Andreas Tille wrote:
| R is not team maintained and Dirk is not reading all threads on Debian
| Science - make sure you CC him (as I did) if you want to be sure he
| notices your mail.
Well ... procmail still sticks it into the same folder and I don't always
find time for this one. But I saw the mail earlier. I am also CCing Don who
is (when he has servers) building thousands of r-*.deb packages automagically.
I second the upbeat mood. This is good. I would have preferred discussions
about design before standards get established -- but he who does the work get
to set the rules. That's you so far.
| > adding some possibly useful extras:
| >
| > * automatic substvars for known dependencies
|
| That's very appreciated and helps definitely to prevent errors since
| sponsees as well as I myself forgot to sync Build-Depends with Depends
| (versioned and unversioned). I verified that the package works as
| expected at least with the random example r-bioc-affy.
Our Depends also need to cover R's "Imports:" which we will not see via ldd. I
presume you have that covered, I just thought I'd mention it.
| > * automatic generation of debian/ from an R package tarball
|
| This could save even more time to create R packages and should prevent
| cut-n-pastos.
|
| > I also intend to support, but haven't yet got working:
| >
| > * automatic handling of dpkg buildflags
|
| To make sure I understand fully what you want to describe: Are you
| talking about hardening flags etc?
|
| > * generation of autopkgtests without copy-paste errors
|
| Cool! What about running the tests also as Build time tests (see
| #752609).
I had once tried to bring some perspective from the R ecosystem to that, but
as I recall I pretty much failed to get my point across. R already does /a
lot/ here via R CMD check, and it may be worthwhile to milk that angle rather
than to shoehorn R (which builds packages somewhat idiosyncratically) into
Debian's framework. Anyway, minor 'day 2' detail.
| > It might also be interesting to explore:
| >
| > * handling binary dependencies between R compiled extensions
|
| What exactly do you mean here? I admit I'd welcome if this dh module
| would be available in sid soon to enable switching packages to it to get
| it fully tested soon. This kind of features might wait for later
| versions.
|
| > * (optionally) building vignettes
|
| Might be nice for additional testing but also not really needed in
| a first usable version.
R user expect them, and get them when they install directly from CRAN.
|
| > I have tested it with a reasonably large collection of d-science and
| > d-med R packages, from both bioconductor and CRAN, and it appears to
| > work.
|
| I'd be happy if you would commit this work once dh-r is available to
| spare me some duplicated work.
To me github is as good / preferable. Other DDs have no issue developing via
GH. I'd maybe make alioth another remote or mirror.
| > However, this is pretty much my first stab at perl so it would
| > certainly benefit from oversight from someone with perl experience.
| >
| > I would be interested to hear from R package maintainers 1) whether it
| > works and 2) any features not listed above which you would be useful.
|
| I think I answered this above.
I am happy to help / advise as well. I am a somewhat active package author on
CRAN. Happy to get this right, happy to also talk about re-starting Don's
effort to get ALL of CRAN into .deb (possibly via secondary repos). There is
no reason we can't.
Gabor Csardi also builds every thing on r-hub (http://builder.r-hub.io)
[which still isn't fully released / deployed but "close" ]
| Thanks a lot for your very welcome work
>From me too. Pushes the cart down the road in the right directly, and by a
good amount.
Dirk
--
http://dirk.eddelbuettel.com | @eddelbuettel | edd@debian.org
Reply to: