[pkg-bioc] how to proceed?

[Dirk Eddelbuettel]

On 4 February 2005 at 20:55, Egon Willighagen wrote:
| 
| Hi all,
| 
| since things are getting started... I guess first things we need to talk about 
| are these:
|
| - package name system (r-bioconductor-X was mentioned)

That is adressed in the Debian R Policy "draft" posted on 30 Dec 2003 (yes,
2003) to r-devel and debian-devel (here is a link, thanks to Google
http://lists.debian.org/debian-devel-0312/msg02332.html ) The Policy "draft"
is of course outdated by some practice right now -- don't take it to
religiously.

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.

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

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

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 ]
* 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

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.

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

All great questions.  Let's keep it going.

Dirk

-- 
Better to have an approximate answer to the right question than a precise 
answer to the wrong question.  --  John Tukey as quoted by John Chambers