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

["Steffen Möller"]

Frederic, this is real impressive - many thanks. Myself I had not yet found
the time to proceed past the wget of CRAN :-)

Dirk has already answered the questions from how I read it. I'll just add a
few comments when I feel less redundant. Should you think that I could
possibly help online with anything, contact me per email or feel free to
skype me as steffen_moeller.

> | 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?
The blacklist should be the default, IMHO, too. Hypothetically speaking, if
the maintainer of the Debian package thinks than an autobuild would be
equal/superior to his maintained package, then the maintainer could just
join the alioth bioc group and have his/her package removed from that
blacklist. He could then upload this package to Debian.

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

And maybe, eventually, we could extend this table / hash / array to specify
the extra dependencies or whatever that kept the package from being built
nicely in the first place.

> | 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.
Is it only pbuilder or a wanna-build variant?

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

This knowledge-base on Debian-packageing should in my view not be specific
to the the CRAN repository but somehow also work for BioC.

> | 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.
I am very much agreeing.

> | 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.
They have version numbers for their releases in the path now.
http://www.bioconductor.org/packages/bioc/1.8/src/contrib/
http://www.bioconductor.org/packages/bioc/1.8/html/
but I have not yet checked if the access permissions allow to get anything
from there,
http://www.bioconductor.org/packages/bioc/1.8/
seems a good start point.

As a sidenote, BioC has introduced "Views" on their packages. This might be
of interest for the Debian Tags to which my contribution is long overdue,
sigh. See "bridge" as an example with many tags:
http://www.bioconductor.org/packages/bioc/1.8/html/bridge.html

Did you mention the metadata packages on the Wiki or was it me?
I have built several Metadata packages manually about a year ago now, I
think. I should go for their inclusion with the script. People were booking
most of my time in January and February already, it might become March until
I'll find time for this, sadly.

> Thank you so much for revitalising the effort here!  Really, really
> appreciated.  Keep the questions coming!
The same from my side.

Steffen

-- 
Telefonieren Sie schon oder sparen Sie noch?
NEU: GMX Phone_Flat http://www.gmx.net/de/go/telefonie