On Sun, 2007-08-19 at 02:10 +0200, Steffen Moeller wrote: > On Saturday 18 August 2007 22:45:56 Soeren Sonnenburg wrote: > > On Sat, 2007-08-18 at 14:44 +0200, Steffen Moeller wrote: > > > On Saturday 18 August 2007 12:36:41 Soeren Sonnenburg wrote: > [...] > > 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? > > For the packages you listed above you do not really need our Debian gimmicks > for. It is easily installed with a few commands of R. But yes, except that I > would rather go for hgu133 they should all be in, ok the example data needs > the hgu95. I think I am aiming at affylmGUI and RBGL and such that are > standard but do not compile too easily for novices since they require to > install some extra bits. This way we (I include you here :-) ) can show off > with how cool Debian is a bit more.
Well having the core packages in (no matter how difficult it is to
install them manually) is always a good idea... it would be great if you
(or someone else with svn write access) could create a file that
contains the packages one could consider base and maybe start with the
highlights of the other
(microarray,annotation,statistics,graphs,technology) packages.
Something like debian-main/{base,microarray,...} etc.
> > > > 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...
>
> Fine. I personally think we are at about 25 packages in BioC that I'd
> consider
> part of core use cases. We did not have discussed this yet. The packaging is
> automated. Some more pretty printing should probably be done before we
> move bits into Debian main. Technically the packages are functional. Updates
> are happening more frequently than you may think, actually, I would not want
> to do it manually.
If one can create high quality packages in a automated way - fine why
not. However I think in the end it will be semi-automatic (as some final
checking is needed...)...
> > > 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.
>
> Well, check out http://wiki.debian.org/AliothPkgBioc. For more detailed
> R-packaging related issues Dirk <[EMAIL PROTECTED]> is your man.
OK.
Soeren.
--
Sometimes, there's a moment as you're waking, when you become aware of
the real world around you, but you're still dreaming.
signature.asc
Description: This is a digitally signed message part
