Re: Debhelper for R packages
On 08/09/16 23:25, Dirk Eddelbuettel wrote:
> | > * 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.
Yes, R:Depends includes both Imports and Depends.
Package resolution is just by looking if `r-{cran,bioc}-lc(packagename)`
exists, and it doesn't generate an error if dependencies cannot be
found, just prints a warning in the build log.
(It also will complain it can't find packages for internal namespaces,
eg `stats`, but that should be fairly easy to add a check for).
>
> | > * 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?
The plan was to avoid seeing eg, lintian hardening-no-bindnow warnings
on packages with compiled extensions. I tried injecting dpkg-buildflags
LDFLAGS output into the MAKEFLAGS environment for R CMD INSTALL but it
doesn't appear to work. It is possible this is also not particularly
important (and/or might interfere with R's own build config) - I don't
really see security as a major R issue.
> |
> | > * 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.
I suspect our testing is most interesting where non-R dependencies are
concerned, particularly where we remove bundled copies and force the use
of system ones.
As with vignette building below, it requires the set of build-deps to be
much bigger (and particularly for bioconductor, tends to require big
dataset packages available).
My workflow is to run autopkgtest (in an schroot) as a postbuild step,
which tests the built deb (so no workaround for testing a not-yet
installed package is required, and ensuring the binary dependencies are
correct), and autodep8 ensures that there is at least a `library(RLIB)`
test defined for every package.
(stdout from R CMD INSTALL includes "checking if the package can be
loaded" or something like that, but I'm not sure what that is actually
testing in practice)
>
> | > 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.
See, eg, r-cran-rprotobuf (LinkingTo: Rcpp) or r-bioc-biostrings
(LinkingTo: IRanges).
My understanding is that this means that these packages build a binary
extension using header files from another R package, and may link to the
so file from the other package at runtime.
I am wondering if this should be interpreted as a tight dependency on
the LinkingTo: package, eg
Built-Using: r-cran-rcpp (=version) or
Depends: r-cran-rcpp (=version)
or if we need to trigger a transition when a package which can be the
subject of LinkingTo: changes.
I'm speculating a bit here - I don't know how often this is a
problem/how stable in practice package ABIs are. This might just be
adding more work for a rare problem.
> |
> | > * (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.
Similar issue to build-time tests - enlarged build-depend set. I don't
think doing it should be too difficult if we're willing to go down that
route though.
> |
> | > 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.
They probably need some manual checking, since I just ran the
`fix-deps.pm` script in the package and replaced the rules file with a
simple dh invocation, but I'll keep the repos around for that possibility.
>
> To me github is as good / preferable. Other DDs have no issue developing via
> GH. I'd maybe make alioth another remote or mirror.
I would plan to have an authoritative mirror on alioth.
>
> | > 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
>
Reply to: