[pkg-bioc] what's up?

Dirk Eddelbuettel edd@debian.org
Wed, 16 Mar 2005 21:00:06 -0600


Egon,

On 16 March 2005 at 13:14, Egon Willighagen wrote:
| On Tuesday 15 March 2005 03:04 pm, Egon Willighagen wrote:
| > I'm back from vacation, and started up creating amd64 debs for CRAN
| > packages again. You might have seen the commits to Alioth...
| >
| > After 276+ build debs, I found that most actually compile... 
| 
| Done. 448 debs build for CRAN with the script in CVS (v1.9).

Good work!

http://cran.r-project.org/src/contrib/checkSummary.html now shows 504, but we
don't of course need the r-recommended packages, or the ones already packaged.

| The can't-build set is not that large:
| 
| my @cannotbuild = ("genetics",   ## depends on 'gdata' which is not on CRAN

Maybe it is in BioC?

|                    "its",        ## fails with: Error in loadNamespace(name) : 
| There is no package called 'its'

Sort-of a non-issue as this is maintained inside Debian by me. I guess the
loadNamespace thing is an upstream buglet which I never pushed that hard.

What this trips up, though, is that my incarnation of the script did not
attempt to build what was already available according to dpkg/apt. As I have
r-cran-its installed, it never tried to build its here.

So I guess we need a finer breakdown of what to build, or not.

|                    "LDheatmap",  ## depends on genetics which cannot be build
|                    "mimR",
|                    "r.matlab",   ## problems defining the dependency... it 
| complains about the '.' in the name

Ok, that would be a bug. Can you try to fix that?

|                    "RmSQL", "ROracle",
|                    "RSQLite",    ## has some Windows libs that trip lintian up
|                    "RScaLAPACK", ## need to sort -dev packages out
|                    "rsprng",     ## need to figure out why this fails

Also available in Debian as r-cran-rsprng. So as above for its.

|                    "RNetCDF",    ## doesn't find netcdf in /usr

I can't remember how I patched that, but I could look it up. I think the
configure in rnetcdf needs some help.

|                    "SciViews",   ## depends on tcltk but is not on CRAN

Errr, tcltk ships with r-base-core!!  But I think it needs some tcltk extra
we may not have. I've lost track. 

|                    "seao",       ## fails with Lintian warning: W: seao 
| source: maintainer-upload-has-incorrect-version-number 0.2.1-0.r2d.1; W: seao 
| source: binary-nmu-debian-revision-in-source 0.2.1-0.r2d.1
|                    "seao.gui",   ## depends on seao
|                    "spdep",      ## fails with: Error in .DESC[["Package"]] : 
| subscript out of bounds
|                    "survey",     ## fails with: Error in open.connection(con, 
| "rb") : unable to open connection
|                    "udunits",    ## dep=udunits not in Debian

I have a local package of udunits and -dev here which I could send you. I am
a little unsure if we can redistribute this. NCAR has odd copyrights.

|                    "uroot",      ## depends on tcltk but is not on CRAN

Wrong, see above.

|                    "IDPmisc",    ## fails with: Error in loadNamespace(name) : 
| There is no package called 'IDPmisc'
|                    ## BioC: can't do annaffy as we lack GO and KEGG data pkgs
|                    "annaffy",
|                    ## the next list of packages is mentioned in CRAN's 
| Description subdir
|                    ## but the tar.gz is not on CRAN. Dates for last test are 
| behind package name
|                    "gmp",        ## 2005-02-21
|                    "boa",        ## 2005-02-21
| );
| 
| my @cannotbuildamd64 = ("rpvm",        ## fails 
| with: /usr/bin/ld: /usr/lib/gcc-lib/x86_64-linux/3.3.5/../../../../lib64/libgpvm3.a(pvmgsu_core.o): 
| relocation R_X86_64_32 can not be used when making a shared object; recompile 
| with -fPIC
|                         "rgl",         ## fails with: 
| usr/bin/ld: /usr/X11R6/lib/libGL.a(glapi.o): relocation R_X86_64_32 can not 
| be used when making a shared object; recompile with -fPIC
| );
| 
| I've not looked into these problems.

It's a known Debian bug, and I had a lengthy argument with its maintainer who
refuses to fix this. It's broken upstream, but simply needs a better Makefile
just like the one Kai, Elijah and I produced for SPRNG when I needed SPRNG
for rsprng and R's SNOW.

But it shows that our needs-to-build / cannot-build info needs another
per-architecture dimension.

| Ok, what remains to be done before actual setting up a repository?
| - bugs db on Alioth?

I'm not too concerned about that so I'll let Matt venture into that. We could
start by having a repository and not yet announce it widely. A BTS can wait,
in my book.

| - caching of the ChangeLog's

As flat files?  More funky?  Do you want to prototype something?
| 
| For the rest, it seems that the script is doing quite a good job!

Yes.

| Some minor issues:
| 
| 1. the descriptions has too many '.'s... e.g.:
| 
| Description: GNU R package "R Based Genetic Algorithm"
|  R based genetic algorithm for binary and floating pointchromosomes.
|  .
|  Author(s): Egon Willighagen <e.willighagen@science.ru.nl>
|  Date: 2005-03-15
|  .

That is the best I could do in a quick job with Perl. Better Perl wizardry
welcome.  It;s difficult, though, as the DESCRIPTION format it not enforced
by CRAN.  What is done here is done via a smart Perl formatting heuristic. I
think we'd waste out time trying to better that.

One day we may have DESCRIPTION stored in a db anyway ...

| 2. Maintainer: Dirk Eddelbuettel <edd@debian.org>
| 
| Which should probably now say something like:
| 
| Maintainer: Alioth collborative packaging for CRAN and Bioconductor 
| <pkg-bioc-devel@lists.alioth.debian.org>

Yes, of course.  The name is good, but a bit long (and with a typo).  Maybe

 Maintainer: Debian CRAN/BioC packaging group <pkg-bioc-devel@lists.alioth.debian.org>

or

 Maintainer: CRAN/BioC packagers <pkg-bioc-devel@lists.alioth.debian.org>

which fits one line.

Good work, Egon. Thanks for pushing the cart that much further along.

April 15 is the deadline for DSC2005 submission if we wanted to jointly talk
about this.  Would make for a nice deadline (August) for actually having
something working :)   Any takers?

Dirk

-- 
Better to have an approximate answer to the right question than a precise 
answer to the wrong question.  --  John Tukey as quoted by John Chambers