[pkg-bioc] how to proceed?

[Egon Willighagen]

On Saturday 5 February 2005 03:02, Dirk Eddelbuettel wrote:
> On 4 February 2005 at 20:55, Egon Willighagen wrote:
> | 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.

I'm 100% fine with r-bioc-*. (Though I'm quite used to COLUMNS=250 dpkg -l 
because of kernel images :)

> - 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've not encountered this problem yet, most were BioC packages... if the first 
option (a.b-c-d) is possible, I have a slight preference for that, because it 
would be easier to recognize the original version. Moreover, what would 
happen did do a a.b.c release after a a.b-c release?

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

Good. I took r-cran-boot, which is likely the first in the alphabetically 
ordered list :)

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

Did it manually sofar, which is not that much work...

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

Agreed. Some are unclear, e.g. free for distribution; does that include 
modifications etc, required by the DFSG...

> *  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/* !!

Good,

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

Indeed. In the past I was warned when building a package when Build-depends: 
was not fullfilled, but this seemed not work very well... i.e. I don't think 
it complained about missing build dependencies...

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

I will not be able to do all of CRAN and BioC by myself, but together this 
might a be a nice goal. On the other hand, some might not even be 
distributable... So: as much as possible, i.e. more than those we're 
personally interested in?

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

Related to this... Dirk, you already mentioned a build system... What bits can 
we automate? What bits will we store in SVN? The whole set of debian/ dirs, 
or just one or a few templates? (at least two, one for CRAN and one for 
BioC).

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

Sounds fair. A alioth repository would work fine for me...

Egon

-- 
e.willighagen@science.ru.nl
PhD student on Molecular Representation in Chemometrics
Radboud University Nijmegen
http://www.cac.science.ru.nl/people/egonw/
GPG: 1024D/D6336BA6