[pkg-bioc] how to proceed?

[Steffen Moeller]

Dirk Eddelbuettel wrote:

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

>  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.
>  
>
Right. cran2deb.pl would then extend the dependencies from the CRAN 
package towards build-deps in Debian and the missing ones in CRAN while 
upstream has not completed them.

> | >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.
>  
>
But since it depends on non-free Graphviz ist needs to go to contrib, 
not to main. ..... Aaah, b) gives the answer. I did not know that.

>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.
>  
>
Initial version manual, later automated would scale. I assume some 
config files for cran2deb.pl would to be extended for each package added 
to be automated, imposing some initial effort. .... but you are right 
... if there is something good working in a auotmated fashion then it 
should be used and it should be used in an automated fashion.

> | >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?  ;-)
>  
>
Hm. If I understand you right then this is what I meant with "used in an 
automated fashion" above. The cran2deb I see only for a single package 
at a time. Since the submitter has a working installation of everything, 
just maybe in a not fully up-to-date version, the submitter can provide 
.debs and the submitter can also submit to the build daemons with all 
the dependencies. While it would be nice to submit in an order that 
directly allows the compilation of each package, I do not see this as an 
absolute requirement. But maybe I have understood you wrong. I'd just 
poll for new packages, cran2deb.pl them, try a build and submit if 
successful.

>| >| - 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?
>  
>
Me personally, no. Aren't CRAN debs available from Graz or something 
today? If our packages are successful, then there will be a site I am 
very confident. If not, then we should not worry about it either.

>| 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.
>  
>
Some packages of CRAN seem a bit strange, like the source code of some 
particular book and so on. Not too many would miss these, I think.

Many thanks for your reply.

Steffen