[pkg-bioc] how to proceed?

Sat, 5 Feb 2005 09:35:14 -0600

On 5 February 2005 at 14:12, Egon Willighagen wrote:
| 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 

I agree with that. I should probably change my packaging practice.

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

That is a bad example as it is part of the r-recommended bundle. It has
"super status" on CRAN, and gets installed into a different directory under
$R_HOME. 

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

Agreed, and I've done it dozens times too.  It's just that a) it is so
obviously repetitive and b) there are 500 candidate packages and we feel
compelled to automate this.

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

I don't follow. It should have failed, not warned. Odd.

I think a good long-term goal is 'apt-get'-able status of CRAN. We need to
build a simple framework that creates a hierachy of downloadable packages,
with minimal user intervention, care and feeing.

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

Alioth is always short on diskspace though. But we can/should probably start there.

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