On Sat, 2007-08-18 at 14:44 +0200, Steffen Moeller wrote: > On Saturday 18 August 2007 12:36:41 Soeren Sonnenburg wrote: > > On Tue, 2007-08-14 at 21:26 -0500, Dirk Eddelbuettel wrote: [...] > > esoteric/brand new research/unstable R-packes. However I would want to > > see the more mature bioconductor packages in debian... > > Again, I think we can agree on this,
OK great. > > Thinking about it, *I* think it would be best to proceed in a similar > > way as the texlive people, i.e. have debian packages for all major > > categories which include the major mature R-packages of that category > > > > r-bioc-base > > r-bioc-microarray > > r-bioc-annotation > > r-bioc-statistics > > r-bioc-graphs > > r-bioc-technology > > Hm. I kind of like it, though I rather see this implemented as virtual > packages that come rather naturally from the Biotags that BioConductor > assigns to itself. Well I don't know how much should be split up. But I guess this depends also on the number of debian ready packages we are talking about? The next problem is I don't really know how to judge whether a package is 'ready for debian' or not. One could of course start with the core/essential packages and then slowly increase the package number. Robert Gentlemen suggested to start with the packages in BioCLite, which is affy affydata affyPLM annaffy annotate Biobase Biostrings DynDoc gcrma genefilter geneplotter hgu95av2 limma marray matchprobes multtest reposTools ROC vsn xtable. What do yo think? > > The remaining R-packages could be packaged as single debian-packages as > > you proposed to do it and maybe even hosted a bioconductor.org? In case > > a package seems more mature it can enter any of the categories and one > > could add proper conflicts/replaces as an upgrade path. BTW, this also > > solves the `not-up-to-date issue', as more mature packages don't require > > weekly/monthly updates. > > Hm. I am not sure. The problem with hiding it all is that we also do not use > apt-cache search to find the proper BioC packages in the first place. We hide > this information away in the superpackages. It also impedes the communication > of Debian users with R developers and the assignment of Bugs. Yes you are right, that may be problematic. If we don't talk about hundreds of packages it is probably also OK... > Btw, wouldn't you be interested to join our effort? I'd offer sponsoring > SHOGUN for Debian as a compensation :-) Indeed I am interested, but I don't have any experience with debian+R other than from packaging shogun-r. So I wonder whether for there exist general cdbs helpers for r & bioc. Also I am still confused that r-base-dev contains no header files (they are all in r-base-core) and that all the libR.so has no SO name (at least objdump -p /usr/lib/R/lib/libR.so | grep SO does not report anything). So from my understanding the only build dependency is r-base-core, but how does one ensure smooth upgrades when switching to new (potentially incompatible) R releases? Regarding shogun, Torsten Werner is already sponsoring the uploads - so don't worry :-) > Many greetings from the fairly sunny Baltic Sea to my former home Berlin Actually I am planning to be at the baltic sea next weekend to take part in the 'vilmschwimmen'! Soeren -- For the one fact about the future of which we can be certain is that it will be utterly fantastic. -- Arthur C. Clarke, 1962
signature.asc
Description: This is a digitally signed message part
