[pkg-bioc] Re: My first steps with cran2deb.pl

[Dirk Eddelbuettel]

Salut Frederic,

On 27 December 2005 at 17:41, Frederic Lehobey wrote:
| I have successfully completed a complete run of it on the i386, sparc
| and powerpc architectures (running sid).  kfreebsd-i386 is in progress
| (on a slow machine).

That's pretty impressive. May have been fine to stop after one arch and
settle the questions, but the more the merrier!
| 
| I have updated http://wiki.debian.org/DebianCRAN accordingly (work
| still in progress at the time of writing).
| 
| Here are my questions:
| 
| 1/ I have noticed some of the packages in CRAN that are automagically
| built by the script are actually already in the official Debian
| archive.  What is the goal for them (ultimately)?  Having them built
| by the script or being blacklisted from it one way or another.  In
| other words, is it interesting to keep and track their status with
| respect to automatic build?

My perspective always was that we should _not_ autobuild what already is in
Debian.  Two main reasons: a) Some of these packages are/were harder in terms
of Depends and configuration (the snow/mpi/pvm/sprng complex is an examples);
and b) I was assuming that the humanly maintained packages would always be
more up to date.  I still think this holds, although Doug is proving me wrong
on some of his r-cran-* packages :)  

I had meant to give the script a spin over the holdidays, but haven't. Last
time I updated it, it still contained a blacklist of packages to skip
"because they are already in Debian".  I still think that is a good idea. 
Comments?

One side-effect of this is that we need to fix the Wiki page where Steffen
commented on build difficulties for a packages already in Debian. This proves
a) above, but as per this discussion, shouldn't really have been tried
anyway.  Unless folks disagree --- let me know your thoughts, and / or
volunteer to edit the page :)
 
So to summarize: One table / hash / array we need to keep up to date in the
script is the list of packages to skip.

| 2/ How am I supposed to deal with dependencies between newly built
| CRAN packages?  More precisely, if the necessary dependencies stated
| on http://wiki.debian.org/DebianCRAN are available in the build
| environment (from the Debian archive), then a huge list of CRAN
| packages can be built.  However, some of the failing ones (at first
| pass) simply need that some of the newly built packages be added to
| the build environment.  What it the proper way to do it?  Install them
| `by hand' with dpkg -i?

Pretty much, yes.  Unless you use an autobuild environment like pbuilder (to
which we need to ultimately migrate) which installs them for you --- provided
you declared the Build-Depends.

So the second table to keep up to date is the mapping between CRAN package
Depends: and Debian Depends --- where it can't be "guessed" via the
r-cran-$CRANNAME rule.
 
| 3/ Some failures are architecture dependent (mostly endianness
| problems for powerpc and sparc according to error messages).  How to
| deal with that?  Setup some exclusion mechanism similar to
| `cannotbuildamd64'?  (Then, there will be as many variables as
| architectures.)

I'd say postpone / take offline.  That is really an upstream issue for these
packages.  Finding this is a a HUGE benefit and may eventually win us friends
in the R world. But so far we simply cannot assume that 600+ packages had
ever been built on all the arches we have at our disposal.  I'd assume
powerpc (Mac OS X), i386 and amd64 and nothing else.
 
| 4/ No progress so far with BIOC.  I have failed to find anything in
| the http://www.bioconductor.org/packages/bioc/devel/src/contrib/html/
| directory stated by http://wiki.debian.org/DebianBIOC .  I have not
| found any proper newer location.

Skip for now til you're happy with CRAN. Also check with BioC. I built all
but one successfully for the latest Quantian some three weeks ago (but from
inside R, not using the script). 

| 5/ I have noticed the following warning when installing the built
| packages (and some of the packages already in sid):
| 
| Ignoring deprecated option --htmllists called from postinst or postrm script.
| 
| I have not yet searched its origin.

See the changelog for r-base-core, and a couple of r-cran-* packages. The
option used to be supported upstream, but that stopped in R 2.2.0. I patch
the R upstream package to emit that string so that we get reminded to fix all
offending packages.  The postinst and postrm should no longer call R to
update the html index; this is now done by R when help.start() is called.
Hope this explains it -- cran2deb.pl needs updated postinst/postrm templates
too.
 
Thank you so much for revitalising the effort here!  Really, really
appreciated.  Keep the questions coming!

Amicalement,  Dirk

-- 
Hell, there are no rules here - we're trying to accomplish something. 
                                                  -- Thomas A. Edison