[pkg-bioc] State of BioC compilations

[Dirk Eddelbuettel]

On 11 February 2007 at 00:51, Steffen Moeller wrote:
| On Saturday 10 February 2007 04:42:22 Dirk Eddelbuettel wrote:
| > On 9 February 2007 at 16:09, Steffen Moeller wrote:
| 
| > Agreed. (But I see that your downloads set "Rversion=2.5" so maybe this
| > opens the door to some changes we don't have in 2.4.1 ...
| 
| I got to that conclusion, too. I do not know why I thought we'd be running R 
| 2.5 in unstable :-/ 

Ahhh :)  In which case I shall be starting over. Are you amending the wiki? 
[ We should also put the script(s) you have there into CVS, no ? ]

| > | Sorry, I meant the order at which the packages' .tar.gz files are
| > | unpackage and dpkg-buildpackage is called. The detection of missing
| > | installs by dpkg-buildpackage is perfectly fine ... but that is too late
| > | and ends the build process.
| >
| > I'm still confused. When? Where? What?
| 
| With the --ignore option added such that the script does not die on errors, it 
| is no longer too bad. However when I have B depend on A and C depend on A, 
| then the build order should be A,B,C, or A,C,B, not anything else. I'd then 
| go for a sudo dpkg -i for the fresh packages that have dependencies. Now I 
| basically need to run the script multiple times. 

AFAIK that has always been the case.  We need a smart and patient coder to
look at Seth's recent R-News article and do some graph-theory work to unwind
the graph.  Basically, Albrecht's Perl script always had the multiple
itertations by stacking up the Depends, and if anything, I probably broke
that code.

| > | > Not bad!  54 down, 900 at CRAN to go :)
| ../bioc$ ls builds/r-bioc-*|cut -f1 -d_| sort|uniq|wc -l
| 88
| ../cran$ ls builds/r-cran-*|cut -f1 -d_| sort|uniq|wc -l
| 448
| 
| We go the more essential ones now as Debian packagse. 

Which was always the reason they were packaged: harder Depends etc pp --
consider eg "your" r-cran-rmysql

| The problem that I   had 
| reported on the graph library was due to my local R_LIBS env setting ... :-/

Tst tst.

| > | Some are already done. We'd now need a repository. We once had the OK to
| > | use Alioth for that. Though I presume we should not go such public before
| > | having improved on our automisation a bit.
| >
| > I want to see several weeks of sustained builds to the level that, say, Uwe
| > Ligges does for Windoze before I go "public".
| >
| > I tried some builds following the recipe at
| > http://wiki.debian.org/DebianBIOC but no luck. 'cran2deb bioc' dies trying
| > to get the meta-information. It ends on
| >
| > [...]
| > Patterns are determined for bioc
| > Could not open description file at 'html/Biostrings.html'
| > Could not open description file at 'sources/../html/Biostrings.html'
| > print() on closed filehandle FILE at ./cran2deb.pl line 762, <PIPE> line
| > 82. readline() on closed filehandle FILE at ./cran2deb.pl line 785.
| > Undefined subroutine &main::lowerCase called at ./cran2deb.pl line 812.
| This does not happen for me. The "Could not open" reports are much reduced 
| once you have downloaded them once.

Well, how am I supposed to download them?  Why is that not documented in the
wiki?  

I mean, I agree that BioC is _harder_ because of their darn hidden web
layers, but it should be possible, or we have no bioc project here, no?

| > and the code looks somewhat scary around lines 762 et al.
| It _is_ scary. I took one "buh!" off the code, still frightening, though.
| 
| I'll look through the Wiki-based instructions another time.
| 
| The download script needs to be going for all packages rather than only the 

I think so too.

I have been thinking for a while though that the code in cran2deb / CRAN2DEB
is just plain wrong and too complicated. I think we should just borrow what
install.packages() et al (incl their bioc sibblings) do and build up the info
from inside R.  All the info is there. Everything.  That should also be very
very scriptable using the littler package we have in Debian now.  Then we'd
"only" needed to deal with the version / name mapping on the Debian side
which we could also do in R or in Perl.  Anyway, we have working Perl code so
let's crank it --- but I have to say it is scary code in places...

And didn't Andrew try that R-Depends analysis this summer for the CRAN part?
Isn;t that why we now need SQLite?

| lite. For tilingArray I need r-cran-pixmap which does not work for me. The 
| rcurl packages I found only with Omegahat. I played with something close to 
| supporting them in the script, but not seriously.

I think you are right and I was mistaken. It does not exist on CRAN. We could
always do one or two inofficial r-omegahat-* package to allow the builds to
prosper.

Dirk

-- 
Hell, there are no rules here - we're trying to accomplish something. 
                                                  -- Thomas A. Edison