Re: Short report on Debian at UseR! 2007 conference at Iowa State Univ.
Hi Soeren,
On 21 August 2007 at 11:20, Soeren Sonnenburg wrote:
| 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
Yes. debian/rules just calls /usr/share/R/debian/r-cran.mk which has the
required smarts, and provides the infrastructure centrally.
E.g. a good example of how it's nice to have the code in one place (as
opposed to dozens of debian/rules files) is that just recently I learned about
a neat x11 framebuffer server wrapper, so calling 'R CMD INSTALL ...' inside
pbuilder will think it has x11 -- nice one. Kudos to Charles Plessy who had
used it somewhere else. Now once I upgrade the R package with that, we'll
have it centrally; a few packages need that and I can just test for presence
of that wrapper and if found, use it. End of digression :)
| 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
Fair point -- and we just don't! I think a need for this arose only once in
ten years of R development in Debian when R 2.0.0 changed enough internals to
warrant it. In that case I just hand-rebuilt all of the r-cran-* I
maintained and bugged the maintainers of the other ones. Worked well enough.
There isn't really enough use of R outside of its own packages to warrant the
heavier hand of encoding major versions, and requiring builds. CRAN package
authors typically upload new packages for new R versions as the CRAN archive
is pretty adamant about tests with R CMD check against current, patched and
devel versions of R.
| 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...
Yes. Remember that libR.so is not an exported API (as stated multiple time in
the R docs) and not known to ld.so and friends. So this doesn't have to
behave like libz or libjpeg with soname encodings, multiple versions, ...
| 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...
But only for 'visible' libraries in /usr/lib etc.
| > | 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,
'du -csk /usr/share/R/include' yields 420k. I have thought in the past about
splitting them off, but weighted that against the total size of the package,
the savings are so small as to not matter.
| 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?
Trust me that for almost every R installation you want both r-base-core and
r-base-dev. Exactly what would we achieve by moving them around, other than
a few kilobytes of header files that would be in the 'arch all' package
r-base-dev rather than in each binary r-base-core? Also, these may have
arch-specific configure results in them so I could create new and subtle bugs
by moving them. I'd rather not, unless you have a real issue with this.
| > | 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...).
but BioC != CRAN. BioC tags releases to R releases. CRAN doesn't. So this
does not apply as such. And besides, R packages typically test for the R
version themselves, so no need to double it via soname encodings.
| > 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...
I was probably thinking of Ggobi and/or its predecessor Xgobi which was
linking against R, but that seems to have changed.
So RPy or my own littler may be better examples. For littler, we use the path
explicitly:
edd@ron:~$ ldd /usr/bin/r | grep lib/R
libR.so => /usr/lib/R/lib/libR.so (0xb7c41000)
libRlapack.so => /usr/lib/R/lib/libRlapack.so (0xb79f5000)
edd@ron:~$
This one could break. So far it hasn't :)
Hope this helps, Dirk
--
Three out of two people have difficulties with fractions.
Reply to: