On Mon, Sep 15, 2008 at 11:46 AM, Patrice Dumas <pertusus@xxxxxxx> 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_Paket> 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@xxxxxxxxxxxxxx> Head of St. Margarets Bay, Nova Scotia _______________________________________________ Fedora-r-devel-list mailing list Fedora-r-devel-list@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-r-devel-list
