On Sun, 2007-08-19 at 20:15 -0500, Dirk Eddelbuettel wrote: > Hi Soeren, Hi Steffen
Hi Dirk,
[lots of agreement that would want to have more high quality R packages]
> | > Btw, wouldn't you be interested to join our effort? I'd offer sponsoring
> | > SHOGUN for Debian as a compensation :-)
> |
> | Indeed I am interested, but I don't have any experience with debian+R
> | other than from packaging shogun-r. So I wonder whether for there exist
>
> Look at any of my existing r-cran-* packages, and you see that they use a
> _very_ formulaic approach which is even distilled into a one-line
> debian/rules files, thanks to a) the standardization at the R package level
> (that, interestingly enough, is inspired by Debian) and b) the magic powers
> of cdbs which we use in the file /usr/share/R/debian/r-cran.mk --- which does
> all the actual package building and installing and provides the code for the
> one-liner calling it. So the key really is that Debian Policy is embedded in
> the is r-cran.mk file. The other debian/* files are standard.
OK, I just had a look at r-cran-fseries, it is indeed a one-liner as you
said. So creating debian packages from cran-r-packages seems easy. What
I still don't understand is how you make sure that a package remains
compatible with future r-versions (I could not find any indication that
this is done via dependencies/conflicts). Taking the r-cran-fseries
package as an example:
$ dpkg -L r-cran-fseries | grep .so$
/usr/lib/R/site-library/fSeries/libs/fSeries.so
$ ldd /usr/lib/R/site-library/fSeries/libs/fSeries.so
linux-gate.so.1 => (0xb7f07000)
libRlapack.so => /usr/lib/R/lib/libRlapack.so (0xb7873000)
libblas.so.3 => /usr/lib/atlas/sse2/libblas.so.3 (0xb7295000)
libgfortran.so.2 => /usr/lib/libgfortran.so.2 (0xb71fe000)
libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb71d9000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb71ce000)
libR.so => /usr/lib/R/lib/libR.so (0xb6ef3000)
libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb6dab000)
libg2c.so.0 => /usr/lib/libg2c.so.0 (0xb6d83000)
/lib/ld-linux.so.2 (0x80000000)
libreadline.so.5 => /lib/libreadline.so.5 (0xb6d51000)
libpcre.so.3 => /usr/lib/libpcre.so.3 (0xb6d2c000)
libbz2.so.1.0 => /lib/libbz2.so.1.0 (0xb6d1c000)
libz.so.1 => /usr/lib/libz.so.1 (0xb6d07000)
libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb6d03000)
libncurses.so.5 => /usr/lib/libncurses.so.5 (0xb6cc2000)
From that one can see that fSeries.so is dynamically linked
to /usr/lib/R/lib/libR.so ... However libR.so has no SO name and if
incompatible changes happen in R, that package will just not work until
it is recompiled...
I think the solution other people are using is to explicitly encode the
version in the .so file, e.g. libR-2.5.so (setting the sonmae to
libR-2.5.so) and including the version name in the package name, i.e.
r-base-core version 2.5 => package r-base-core2.5...
> | general cdbs helpers for r & bioc. Also I am still confused that
> | r-base-dev contains no header files (they are all in r-base-core) and
>
> Well, Doug chose the name years ago; r-base-dev is meant to provide all
> dependencies so that R users can do call install.packages() from R and not
> fall over because headers and libs such as readline or curses are missing; it
> is not a -dev package in the normal sense (which doesn't work for R as R is
> not a library you compile against).
I don't understand... A R user that just wants to use R as is (i.e. not
compile/install new packages) should not need to install header files,
but all the header files are in r-base-core. So I still don't see why
the files necessary to build R extensions (like header files) are not in
r-base-dev?
> | that all the libR.so has no SO name (at least
> | objdump -p /usr/lib/R/lib/libR.so | grep SO does not report anything).
>
> Because ld.so does not see /usr/lib/R/lib as it doesn't need to know about it
> (as one typically does not compile against it). [ You have a harder job with
You are right for many cran packages that are written in vanilla R
(contain only .R files...), but for cran-packages containing
C-extensions that is a problem (I remember having installed bioC locally
and having it to recompile when a newer R version entered debian...).
> shogun and a better example for you would be Ggobi and r-cran-rggobi so look
> there instead of comparing with random CRAN package that are called into R --
> I believe you call R into Shogun so the flow is different requiring a
> different setup. ]
r-cran-ggobi only depends on r-base-core (>= 2.5.0) ... so I don't see
anything providing a smooth upgrade path...
> | So from my understanding the only build dependency is r-base-core, but
> | how does one ensure smooth upgrades when switching to new (potentially
> | incompatible) R releases?
>
> I don't follow exactly what the questions is. Maybe take this to private
> mail?
Yes I am sorry, we can discuss this in private and maybe then only post
the solution...
> Good to be discussing R on debian-devel :)
You started it right :-)
Soeren
--
Sometimes, there's a moment as you're waking, when you become aware of
the real world around you, but you're still dreaming.
signature.asc
Description: This is a digitally signed message part
