Hi Thomas,
On 10 November 2005 at 15:25, Thomas Friedrichsmeier wrote:
| Package: r-base
| Version: 2.2.0.final-4
| Severity: normal
|
| I'm trying to package an application that links against libR.so (rkward,
| ITP-bug: #333392). As far
[ I know, did you see my follow-up to your ITP? Hadn't heard back from you,
but maybe you just didn't CC me ... Anyway, we can take this off-line and
may as continue 'auf Deutsch'. ]
| as I understand, the whole point of providing the shared library,
| instead of only the static linked version of R is to allow applications
| to embed/link against R.
I don't think that's "the whole point". Shared libraries have many advantages
(e.g. multiple copies running at the same time use the memory only once, not
N times) and are not an indication of this being used primarily as an
external library.
| However, since libR.so is currently located in /usr/lib/R/lib, and only
| there, I can not link against it without using rpath. I do not know
| about the relevant policies, but I really think, libR.so should be in
| /usr/lib, or at least there should be a link to libR.so in /usr/lib.
|
| Could you please provide such a link in the r-base-core package?
I'd rather not. R is not a general purpose library (like, say, libjpeg) and
does therefore not make itself available via /usr/lib. The only generally
exported part of R is capsuled well and cleanly in r-mathlib which has a
proper external API, headers, etc pp and therefore lives in /usr/lib. But
libR.so is really mostly internal, with a few hooks for advanced use.
Also, I'd argue that the request of a _single_ package is not enough to
further clutter a system directory.
There are other precedents like Ggobi -- see here:
[EMAIL PROTECTED]:~$ ls -l /usr/lib/R/lib/
total 2844
-rw-r--r-- 1 root root 1759544 Oct 24 19:29 libR.so
-rw-r--r-- 1 root root 1139796 Oct 24 19:29 libRlapack.so
lrwxrwxrwx 1 root root 27 Jun 25 14:20 libggobi.so ->
../../ggobi/lib/libggobi.so
lrwxrwxrwx 1 root root 28 Jun 25 14:20 libgtkext.so ->
../../ggobi/lib/libgtkext.so
[EMAIL PROTECTED]:~$
So to make Ggobi [ a standalone binary package with Gtk frontend, similar
in spirit to your R Gui in as much as it provide a GUI ] available to R
[ so this is symmetric: here it is R that is doing the importing ], I simply
link the libraries that are "non-globally" exported by Ggobi [ i.e. do not
use /usr/lib but the packages's own /usr/lib/ggobi ] back into a directory
known to R based on its own library settings [ with /usr/bin/R being a shell
script that use LD_LIBRARY etc pp ]
I would think that you can do something similar. You can safely assume that
the /usr/lib/R location will not go away.
You could also look at other packages embedding R. The Postgres package based
on Joe Conway's upstream code comes to mind. See postgresql-8.0-plr /
postgresql-7.4-plr. Then there is RPy but I can't remember what it
does.
Let me know your thoughts.
Regards, Dirk
|
| Thomas Friedrichsmeier
|
|
| -- System Information:
| Debian Release: testing/unstable
| APT prefers unstable
| APT policy: (500, 'unstable'), (500, 'stable')
| Architecture: i386 (i686)
| Shell: /bin/sh linked to /bin/bash
| Kernel: Linux 2.6.14-1-686
| Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
|
| Versions of packages r-base depends on:
| ii r-base-core 2.2.0.final-4 GNU R core of statistical
| computin
| ii r-recommended 2.2.0.final-4 GNU R collection of recommended
| pa
|
| Versions of packages r-base recommends:
| ii r-base-html 2.2.0.final-4 GNU R html docs for statistical
| co
| ii r-base-latex 2.2.0.final-4 GNU R LaTeX docs for statistical
| c
|
| -- no debconf information
--
Statistics: The (futile) attempt to offer certainty about uncertainty.
-- Roger Koenker, 'Dictionary of Received Ideas of Statistics'
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
