[pkg-bioc] how to proceed?

Sat, 5 Feb 2005 12:07:17 -0600

On 5 February 2005 at 18:46, Steffen Moeller wrote:
| 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.

i) debian/rules doesn't need it. See here from a recent one:

     #!/usr/bin/make -f
     # 							-*- makefile -*-
     # debian/rules file for the Debian/GNU Linux r-cran-zoo package
     # Copyright 2003, 2004 by Dirk Eddelbuettel <edd@debian.org>

     include /usr/share/cdbs/1/rules/debhelper.mk
     include /usr/share/cdbs/1/class/langcore.mk

     ## We need the CRAN (upstream) name 
     cranName	:= $(shell grep Package: DESCRIPTION | cut -f2 -d" ")
     ## and we need to build a Debian Policy-conformant lower-case package name
     cranNameLC	:= $(shell echo $(cranName) | tr "[A-Z]" "[a-z]" | tr "." "-" )
     ## which we can use to build the package directory 
     package		:= r-cran-$(cranNameLC)
     ## which we use for the to-be-installed-in directory
     debRlib		:= $(CURDIR)/debian/$(package)/usr/lib/R/site-library

     common-install-indep:: R_any_arch
     common-install-arch:: R_any_arch

     R_any_arch:
     		dh_installdirs		usr/lib/R/site-library
     		R CMD INSTALL -l $(debRlib) --clean .
     		rm -vf $(debRlib)/R.css $(debRlib)/$(cranNameLC)/COPYING

  So by defining a new meta target 'R_any_arch' that both indep and arch depend
  upon, we're set.

ii) debian/config does not, but then you need to take a step back.  If and
when you think about a way to create these files autoMAGICally as I have done
in the Perl/R scripts, you write these files from the master script (say,
cran2deb.pl) anyway.  And cran2deb can easily detect the presence of an
unempty directory src/ and lay out debian/control accordingly (any vs all;
Build-Depends vs Build-Depends-Indep etc pp)

iii) Getting all the interpackage Depends right is at least as important.

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

Disagree, for two reasons:

a) BioC is actually more stringent than CRAN and only lets "good" licenses
in. CRAN has some grandfathered old stuff.  Rgraphviz always was free.

b) Graphviz is now in main; AT&T adopted a new license. Same with Gobi, but I
am still waiting for a new upstream tarball that actually includes the new
license.

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

Easy, but doesn't scale.  The /worst/ we could do is package a ton of stuff
and then fail to maintain it.  Automation is your friend.  Costlier at first,
much cheaper long-term.

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

No, because you miss the intermediate stuff of how you feed the content of
CRAN and BioC to the buildd. Calling some magic helpers?  ;-)

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

I could live with that compromise. The data packages are huge -- as I see on
Quantian.  BioC also has some topical breakdowns, so we could have
1,2,3,.. of their "sets" in Debian.

But would you, say, have the bandwidth, time, energy to maintain them all?
For years to come?

| suggested or depended on from my point of view.

That may be the best we can do, but it is very scattershot.  Having all of
CRAN in reach of apt-get would be nicer.

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