[Debian-med-packaging] Missing file for unit test in GenABEL
Andreas Tille
andreas at an3as.eu
Tue Jul 1 19:33:54 UTC 2014
Hi Yury,
On Tue, Jul 01, 2014 at 06:41:19PM +0200, Yury Aulchenko wrote:
> > Do you have any reasons to remove the tests from the tarball? I could
> > imagine that larger chunks of data might be used but I assumed that for
> > this very purpose GenABEL.data exists ... and so I did package it for
> > Debian as well.
>
> This was requested by CRAN maintenance team some time (a year?) ago. My understanding this first takes long time to run these tests and secondly RUnit tests are somehow not very stable. Apparently this is not only for GenABEL, but is a general policy (not 100% sure though)
??? I admit it sounds pretty strange to me that there should be a policy
to avoid testing software. At least in Debian we are doing the contrary
and try to add tests whereever possible that can run at package build
time and in periodical tests of the full archive.
> > While this would possible in prinziple I personally really prefer a
> > downloadable source tarball including testing features if any possible.
> > However, if you might have strong reasons I would find ways to drain
> > the stuff needed from the repository.
>
> Not sure what is the best option, but we have a few
>
> 1. use CRAN release, no unit tests
>
> 2. use SVN tag for latest release - easiest for us (but I understand you'd prefer tarball)
>
> 3. we provide the tarball for latest release, including RUnit part on the code on our web-site http://www.genabel.org/
>
> what do you think? I am somewhat afraid that it may be difficult to implement/keep coherent option 3. - to be fair, with me being overstretched, we struggle a bit with keeping sustainable maintenance of the GenABEL-package.
>
> Any other options, anyone?
I admit that having a canonical way to obtain a tarball from CRAN is
quite attractive. Is there any chance to somehow "hide" the tests -
perhaps by renaming the directory the test files are located in - before
uploading the tarball to CRAN so the test will not run there but we can
"uncover" the files again and run the tests. For me this sounds like a
good compromise to fullfill all needs without changing the workflow
drastically.
If you might document this in some README file also other potential
distributors and users could profit from this.
> best wishes,
Same to you and thanks for your quick response
Andreas, keeps on shaking head why CRAN refuses testing ...
> Yurii
>
> >>> On Jun 26, 2014, at 15:47, Andreas Tille <andreas at an3as.eu> wrote:
> >>>
> >>> Hi Yurii,
> >>>
> >>>> On Fri, Jun 20, 2014 at 10:44:43AM +0200, Andreas Tille wrote:
> >>>> Hi Yurii,
> >>>>
> >>>> I'm trying to update the Debian package of GenABEL. Since some time
> >>>> there is an effort to automatically run unit tests of software if
> >>>> available. Since I noticed that GenABEL comes with unit tests I
> >>>> tried
> >>>>
> >>>> $ make test
> >>>> export RCMDCHECK=FALSE;\
> >>>> cd ../../tests;\
> >>>> R --vanilla --slave < doRUnit.R
> >>>> /bin/sh: 2: cd: can't cd to ../../tests
> >>>> /bin/sh: 3: cannot open doRUnit.R: No such file
> >>>> make: *** [test] Error 2
> >>>>
> >>>>
> >>>> As you can see the file doRUnit.R is missing. It would be great if you
> >>>> could include this file into the source diustribution to make sure we
> >>>> can reproduce your exact test procedure in the Debian package.
> >>>
> >>> I cloned https://github.com/cran/GenABEL.git and had a look into the
> >>> code. I realised that the last tag containing the file doRUnit.R was
> >>> 1.6-7. I wonder how you are doing unit testing in the current version.
> >>>
> >>> Thanks for any enlightenment
> >>>
> >>> Andreas.
> >>>
> >>> --
> >>> http://fam-tille.de
> >>
> >
> > --
> > http://fam-tille.de
>
--
http://fam-tille.de
More information about the Debian-med-packaging
mailing list