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 | e...@debian.org