[pkg-bioc] how to proceed?

[Steffen Moeller]

Dirk Eddelbuettel wrote:

>I have no strong feeling for r-bioc-* or r-bioconductor-* names. Both would
>work, and the BioConductor Project itself uses 'bioc' as shorthand. One
>concern with Debian is that r-bioconductor- would "waste" 15 characters in,
>say, "dpkg -l" listings. So there is one precedent right now in my
>r-bioc-repostools package. If we plan to consistently name things, we should
>probably address the issue sooner rather than later.
>  
>
agreed, otherwise we'd need to redo all the packages. I'd still be for 
the long version.

>- Related is the issue of version numbers. AFAIK BioC is more consistent and
>  uses only a.b.c upstream, leading to Debian versions a.b.c-d.  CRAN is
>  messier and has a.b-c upstream --- which some (Chris L.) kept leading to
>  Debian versions a.b-c-d whereas I normalised them to a.b.c-d.  Views?
>  
>
I  am with you - normalisation.

>| - what does the templete debian/ dir look like, and are we happy with it
>
>We have lots of working examples. I generally go back to the most recently
>package r-cran-* package --- you could look at, picking one semi-randomly
>here, r-cran-sandwich from October 2004 for a decent stanzas.
>  
>
The only addition I pledge for is the automated transition in rules 
between indep and arch in dependency of the excistence of a src 
directory. Also, debian/rules could change debian/config from any to all 
at the same time.

>In short, thanks to a) cdbs for debian/rules, and b) the decent
>standardization at CRAN, and c) the existing tools (lots of Perl code in R's
>base; R code in BioC's repostools) which parse all the data -- it is pretty
>easy to automatically generate debian/* files:
>
>* copyright based on DESCRIPTION [ NB we also need to check the terms of the
>  copyright; CRAN has a few packages that wouldn't fit into main ]
>  
>
Rgraphviz springs to mind.

>* changelog is trivial
>* control based on DESCRIPTION and out meta-logic for package-interdependency
>  as well as built-depends on external libraries --- this was first addresses
>  by Albrecht Gebhard in his Perl code which I later extended. Essentially
>  you need human-edited tables that map these depends where needed.
>* rules: pretty trivial thanks to cdbs
>  
>
Well, at least initial packages are _very_ easily done manually. I have 
just done it myself as you know. I think it would be sufficient to find 
ways of an automated update and maybe even upload of the packages.

>That's it for debian/* !!
>
>We then need some meta code to "sort" packages to build those with no
>external dependends first so that those who can depend on this first set can
>be built in a 2nd stage etc pp.
>  
>
As I said - not needed when doing things manually in the first round as 
we have it availabe at the moment. The build daemons and Debian-based 
dependencies do the rest for us, I'd say.

>| - what are our short term and long term goals
>
>A "meta" questions I'd put up:
>
>- What do we try to do? All of CRAN + BioC, eventually?  Just BioC? Just
>  parts of BioC or CRAN ? "Anything", more important to get something going?
>  
>
All the non-data packages of BioC for the Debian main distribution and 
the data packages somewhere else. CRAN we'd do as packages are being 
suggested or depended on from my point of view.

> | Some organisational things we need to talk/be informed about:
>| - alioth uses SVN now? (so something about that, I think...)
>|    if so, how can we access it
>| - how will we release? I guess testing is closed for new packages?
>
>Rather irrelevant as we don't yet know if it makes sense to flood Debian with
>all > 500 packages on CRAN and BioC.  I don't think it does. Maybe we'll end
>up with an infrastructure where people can apt-get automatically generated
>packages, and some extras ones will be manually maintained in Debian... I
>don't really know, and don't think it is the right time to decide that yet.
>  
>
Cheers,

Steffen