[pkg-bioc] State of BioC compilations

[Steffen Moeller]

On Sunday 11 February 2007 16:57:28 you wrote:
> On 11 February 2007 at 00:51, Steffen Moeller wrote:
> | 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.
It is more like "araaarrghhh!" But only those packages for which I did the 
patches should be redone, I think. Unless ... wouldn't you appreciate a 
release of 2.5 for Debian unstable? Or experimental at least? Then we could 
just continue with the bioc devel series.  My problems with the pixmap 
library let me think that 2.5 might be good for CRAN, too, but you are the 
more experienced here.

My problem with the release version is that it is more difficult for the 
Debian users to contribute back to upstream developement. And as long as we 
ourselves are still developing the pkg-bioc infrastructure, I thought that 
the devel packages would be a better fit for our automated packaging. Once we 
are stable, then there should also be a stable repository with the stable 
series...but for the moment.

> Are you amending the wiki? 
> [ We should also put the script(s) you have there into CVS, no ? ]
There are no scripts, really, just some lines to execute from the Wiki. As you 
pointed out in your personal email, that Wiki page had those lines removed by 
accident.

> | > | 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.

Ah.

> | > | > 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 "harder Depends" in the sense of restricting to the minimum I have just 
weakened a bit as I made all packages that were before only made parts of the 
control file's Depends: line also part of the Build-Depends. My reasoning was 
that from my many additions to the %buildDeps, about 99% where exactly as 
stated on upstream's description file. Some packages had the dependencies 
missing, though I found little if at all redundantness from upstream's site. 

Upstream's suggests line is not used at the moment, which it probably should.

> | > | 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".

Well hiding this between the lines: The packages I just compiled I made 
accessible at http://pc02.inb.uni-luebeck.de/pkg-bioc
They are ugly since  have to update (read: simplify) the retrieval of the 
descriptions, still.

> 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...
Agreed, here. All the retrieval of information from the html pages should 
go ... and will go.

> And didn't Andrew try that R-Depends analysis this summer for the CRAN
> part? Isn;t that why we now need SQLite?
I have not grasped yet what to expect from the SQLite bits.

Cheers,

Steffen

-- 

Dr. Steffen Möller
University of Lübeck
Institute for Neuro- and Bioinformatics
Ratzeburger Allee 160
23538 Lübeck
Germany
T: +49 451 500 5504
F: +49 451 500 5502
moeller at inb.uni-luebeck.de