On Mon, Sep 15, 2008 at 11:46 AM, Patrice Dumas <pertusus(a)free.fr> wrote:
On Mon, Sep 15, 2008 at 10:13:26AM +0100, Dan Bolser wrote:
>
> OK, and then packages from Fedora with deps in CRAN that have been
> locally built can be installed right? Can we set up the RPM so that it
> can 'query R for what it has installed' for the purposes of resolving
> such deps?
>
> Is this what happens already?
No, dependencies of a rpm package are set up at build time. And if a
dependency is not in the rpm database it won't be considered to be
fulfilled. This design doesn't allow rpm to track something that was not
installed as a rpm, but the reason is that when installed as a rpm there
is a 'promise' that the package is available for all users, while other
kind of installations cannot make that 'promise'. Maybe there are ways,
in some case to be sure that a package is available for all users
although it wasn't installed through rpm (for example in R, maybe there
are ways to know if a package is installed for every users by not
searching in user paths, only in system paths), but these are not taken
into account in the rpm design. And there are good reasons, indeed, a R
package could be installed system-wide, which is not only R noarch code but
contains some C code linked against a library, and this library isn't on
the loader search path for all the users. rpm would track down the
library too, while R may or may not, in any case it cannot be counted
on, and things become much too complicated in rpm if a knowledge of 3rd
party languages has to be embedded in rpm for things not installed
through rpm.
Yes, unless you prohibit installs using, e.g. "R CMD INSTALL" tools
to inform
rpm of what has been installed should be provided. Even with such a
prohibition,
the tools may be needed to migrate an existing install to the rpm
regime. Since R can
install to various libraries, you have to consider the problem of
maintaining multiple
corresponding rpm databases, one for each library used by R. One approach
would be to discourage installs to /usr/lib/R/library except via rpm packages.
In practice this means casual experimentation with new packages can continue
as before using some other location, but that a bit more discipline
will be imposed
for installs to the system-wide location. In return, there is more hope that
R libraries packaged as rpm's will "just work" without the problems
that sometimes
occur (configure fails due to differences over versions or locations
for include files)
using R source libraries.
That being said, a way to create a package without actual files that
has
the dependencies can workaround the fact that rpm doesn't know about
packages not installed through rpm.
This is the issue that arises for rpm installs to a user directory, e.g.,
$ rpm -ivh myfile.rpm --relocate /oldlocation=/newlocation
The mkVirtualrpm shell script (German): <
http://ojkastl.de/pub/LinuxClub/>
is supposed to solve the problem of ensuring that the rpm database in
/newlocation is informed of things already installed to /oldlocation.
<
http://wiki.linux-club.de/opensuse/Wie_erstelle_ich_ein_virtuelles_RPM_Pa...
I haven't had time to investigate, but I hope this can provide a
starting point for creating
virtual rpm's to go with R packages. In principle, these virtual
rpm's could also do some
post-install processing to make documentation mimic the distro's
standards, update
index files, etc.
--
George N. White III <aa056(a)chebucto.ns.ca>
Head of St. Margarets Bay, Nova Scotia