Andreas, Don,
Home now after all that R conferencing in Italy and LA -- and thanks again to
Don for a lovely afternoon / early evening outing in LA.
On 30 June 2014 at 18:58, Andreas Tille wrote:
| I know that you checked since we had some conversation about this in
| rstudio WNPP. I told youin this thread[1]: "I also plan such an
| overhaul in June to get all the BioConductor packages refreshed."
| and so I did (and also the other R packages).
Yes, thanks -- it looks better now. I kept three tabs open on my desktop as
reminder to come back to this 'at some point' (and I may still write a script
to compare the CRAN status and what the Debian DB has -- mainly to finally
learn about the Debian DB back end).
Right now, I see these packages as out-of-date (and I wasn't thorough,
scanning mostly for r-* only)
- debian-med:
catools
r-bioc-affy
r-bioc-biovizbase
r-bioc-bsgenome
r-bioc-cummerbund
r-bioc-edger
r-bioc-genomicfeatures
r-bioc-gviz
r-bioc-iranges
r-bioc-limma
r-bioc-rsamtools
r-bioc-rtracklayer
r-bioc-shortread
r-cran-bbmisc
r-cran-g.data
r-cran-genabel
- debian-science
r-cran-colorspace
- debichem
r-cran-base64enc
(and a bunch of packages with wrong "policy" as we aim for
r-other-$AUTHOR-$PACKAGE but then I never really finished the Policy so
shame on me)
which is better than it was before.
It would be good if these teams could establish a routine to keep this set
minimal; if they don't than I still fail to see the good it does. [ And for
what it is worth, at all these R conferences I have yet to find a single
person mentioning all those r-(bioc|cran)-* packages ... ]
| I keep on thinking that there is a difference between testing a source
| package on a Debian machine and testing a binary in the chroot it was
| built in. You did not answer how the test is done if not even all the
| preconditions needed for a test are packaged.
Several years ago, R changed how it tests its packages. It used to work from
either the source dir, or the a tarball. These days, it stronly prefers a
tarball.
But post-build is simply not supported by R itself, even though has a _very
robust_ and _widely used_ test system. If we go for automated testing (and
we should, of course, though I'd prefer to see it being optional) then we are
simply better off using 'R CMD check someTarFile_1.2-3.tar.gz'.
Several packages try the test post-build, but __it is not standardized or
even documented__ within the R ecosystem whereas the approach of using
R CMD check someTarFile_1.2-3.tar.gz
is at the same time understood, documented and even mandated.
| I know that there are different testing frameworks - I just packaged one
| of it (r-cran-testthat) to be able to do the testing. This is exactly
| the point I want to make: We need to do the testing on a closed system
| with Debian packaged code to be able to guarantee that the user gets a
| package which was tested with the code we are delivering.
See previous paragraphs. You think as a DD (which is normal) so you want to
test post-build / post-install. That is __not generally supported by R__ so
you are in for some work.
Alternatively, do what R does and use 'R CMD check ...' which automagically
hooks (via mechanisms in the package) into use of RUnit, testthat, ...
BUT it will also require Suggests: as well as Depends:.
I have the "privilege" of having 230+ CRAN packages depend on my own package
Rcpp (aka r-cran-rcpp). So before I send Rcpp to CRAN, I batch-test all of
its reverse Depends. Trust me that based on this sample I do know that
Depends: alone is not enough (though you can instrument R CRAN check ... to
ignore Suggests, it will still fail in some cases).
| > Tests may use Depends: and Suggests: from the DESCRIPTION file so just by
| > building you are NOT guaranteed testability.
|
| Only if we set Build-Depends properly - that's exactly the point I try
| to make.
Then Build-Depends: become a superset of Depends: and Suggest:. You will
need to package another large set of packages. There lies madness. CRAN
already has 5700+ package, and is growing. There is IMHO no point in trying
to package 500+, 1000+, ... packages. We put strain on Debian without
commensurate users.
debian-r.debian.net may be a better answer.
| I would be really happy if you would stop trying to make this personal.
I am not.
But as you are the self-appointed emperor of these teams, I hold you
responsible for an inflation of the package count without commensurate
attention to how 'current' a package is.
Which I consider a quality metric too. I'd rather not see something packaged
rather than see it packaged once and not updated. It is my impression that
this happens (happened ?) more often than not, and I am not happy about it.
And you won't get to stop complaining to you about it simply by telling me
you don't like the complaints. Please keep packaged software current.
And please believe me that I have nothing against "Andreas-the-person". I am
in awe of all you have done for Debian; I am mostly sad about what I see as
counterproductive outcomes (though I acknowledge happily that things are
better now than a few months ago -- keep it up).
And I am also very grateful for the earlier patches against r-cran.mk. They
helped quite a bit.
Now: as for the "dh" transition of r-cran.mk (or another replacement
dh_r-build or whatever). That would be nice. And we can then see how to
opt-in for tests. I will let this rest and see over the next few weeks /
months if Don and I can get this going. We have debian-r.debian.net as a
test bed to try things on, as I remain relunctant to change / break the
current system "just because".
Ditto for a possible r-base-api-N package for R transition. I think Don
convinced me of a way to do this, and as long as I don't forget all the
details I will try to take a shot at implementing this.
Cheers, Dirk
--
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
