[pkg-bioc] Problem building CRAN packages

[Dirk Eddelbuettel]

On 20 June 2006 at 21:46, Johannes Ranke wrote:
| I did not change any of the logic, since I only partly understand it. I
| just added a couple of packages to the "cannotbuild" array, with
| comments like "needs r-cran-thisandthat" or "fails with ...".

Correct. That's what we need there.
 
| I just want to make sure, that I am doing the right thing, before I
| commit those.

Yep.
  
| > | 1) Why are these dependencies not handled in the array that seems to
| > | be made for build dependencies:
| > | 
| > | 	my %buildDeps=(
| > | 	           arules    => ["r-cran-matrix"], ##
| > | 				...
| > | 				...
| 
| Well, in @cannotbuild there is the comment
| 
| 	## List of packages that build once their dependencies are
|     ## available in the build environment.
|     ## To be installed, for example, by something like:
|     ## dpkg -i builds/r-cran-...
| 	## The number in parenthesis is the number of run of this scripts
| 	## found necessary before commenting out the non-build of the package
| 
| And then, there is lines like
| 
| 	   "distr",         # r-cran-setrng.
| 
| This looks like a build dependency to me.

Right.  That list in @cannotbuild is currently pretty large, and we need to
shorten it. But before we address these one-by-one, maybe it is easier to
just complete one full run of the script.

| Later, in the associative array (or however this is called in perl)
| named %buildDeps, build dependencies are specified by lines like
| 
| 	   distr     => ["r-cran-setrng"],

Yep. And we need the right-hand-side values to specify the Debian Depends:.
 
| Only now I noticed that these are even (partially?) duplicated.  I
| understand that the entries in the first array disable the build attempt
| until they are commented out. 

Yes, esp. for things that will never built (Windows-only, special libraries,
maybe non-free stuff we don't want to do now but maybe later etc).

| The later entries are used 
| 	a) to determine if the package requires packages from contrib

>From anywhere, really.  The script should create a debian/control with
Build-Depends that would work on an 'empty' system to pull in whatever is
needed. That's how it works inside the pbuilders.

| 	b) is added to $packages{$package}{'debianbuilddependencies'} 
| 	   which is in turn later printed as $bdps, if not empty.
| 
| Now that I analyzed this, I can tentatively answer the question myself:
| 
| The first array is useful to make the skript proceed, while the second
| array tells the user what he should install in order to make the skript
| proceed.

I was actually working on an extension that would _install_ these while
building (and then remove them).  I didn't get it finished.  For now the
manual way is probably fine.
 
| Please correct me, if I didn't get it right. If I did, my conclusion
| is that it would be preferable to put all build dependencies in one
| place (probably %buildDeps), check for them, build an array of
| unsatisfied build dependencies, print it for the user, and skip packages
| with unsatisfied build-dependencies, instead of aborting.

Right.  Also note that the Build-Depends are inter-depends: we first build R
packages without Depends: so that these are available for other R packages
that have a Depends: on them. [ Still requires installation by the user,
though. ]

But you got the gist of it! 

[...]

| You mean a reason why the directory wasn't cleaned? I can't think of
| anything it would have be special to this package and some others that
| gave me similar errors.

Yes, there could always be bugs in R packages....  Now you know how to
exclude them from the build process :)

[...]
  
| As I said in my last mail to Gregor Gorjanc, I am thinking of an array
| of package names (maybe already including build-dependencies), as input
| to the script. In this way, things that only need to be done once, would
| only be done once (ideally).

Actually, thinking about this some more, and idiom I have used in the past is
to use command-line arguments:

-- if present, loop over @argv, this would give our one, two, ... file mode
-- otherwise use the default of looping over whatever we get from the mirror
   directory, ie 'everything'

Still requires a partial rewrite, though.

Nice work Johannes. You're getting the hang of it. Don't forget to check
changes back in though. I made the mistake of waiting too long.

Dirk

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