Dear all
As agreed with José there is the news of the new release of R2spec.
Have a nice sunday
Best regards, Pierre
======================================================================
There is the latest version of R2spec, I have been working quite a bit on it with the suggestion of faceface from #R on irc.freenode.net to improve this software. Therefore the changelog for this new release is quite long and the list of features added seems also important.
The principle is still the same: make R packages as simple as possible.
Seems there are mainly two sources of libraries for R (Bioconductor and the CRAN) I added two options (--bioc and --cran) that add the Source0 and the URL in the spec file if it has not been defined by the --url option.
From that I aslo considered the case of the noarch packages, it now looks for *.c, *.C, *.cp, *.cpp, *.f and *.F files, if it does not find any it consider the package as noarch and thus adapt the specfile for that.
It also offers the possibility to move the source to %_topdir (defined in ~/.rpmmacros) so that you can directly run the rpmbuild -ba once you have made the small correction advised on the spec file.
That's the main features added, you can see below the changelog for this new release and you can always test and give feed back, report bugs and suggest enhancement on the trac of the R2spec project [1].
The RPMs and sources are available on the git of the R2spec project [2].
Thanks for your attention :-)
[1] https://fedorahosted.org/r2spec [2] https://fedorahosted.org/r2spec/browse
Hey Pierre,
That looks like a great list of changes!
Hello list!
I have been using R (and Fedora) for several years, but I have only just started to look at the R-Repo stuff (thanks to Pierre!). I have only recently used R2Spec, but I found it very convenient and easy to use.
One question that I raised with Pierre previously (and he suggested that I raise it here on list) is the issue of getting the R-library manager to some how 'talk to' the Yum package manager.
I think the first step would be to build a dummy RPM that includes all the R-libraries that come by default with R. Such things as base, lattice, stats, etc., etc. All these libraries could (?) be rolled into an RPM called R-libs (or something), and then when packaging an R-library that depends on 'stats', for example, the dependency would be satisfied by R-libs... Is that possible?
It would be good to know what libraries comes with each version of R by default, and it seems natural to put that information into a specific RPM.
Not sure if that makes sense...
All the best,
Dan.
2008/8/31 Pierre-Yves pingou@pingoured.fr
Dear all
As agreed with José there is the news of the new release of R2spec.
Have a nice sunday
Best regards, Pierre
======================================================================
There is the latest version of R2spec, I have been working quite a bit on it with the suggestion of faceface from #R on irc.freenode.net to improve this software. Therefore the changelog for this new release is quite long and the list of features added seems also important.
The principle is still the same: make R packages as simple as possible.
Seems there are mainly two sources of libraries for R (Bioconductor and the CRAN) I added two options (--bioc and --cran) that add the Source0 and the URL in the spec file if it has not been defined by the --url option.
From that I aslo considered the case of the noarch packages, it now looks for *.c, *.C, *.cp, *.cpp, *.f and *.F files, if it does not find any it consider the package as noarch and thus adapt the specfile for that.
It also offers the possibility to move the source to %_topdir (defined in ~/.rpmmacros) so that you can directly run the rpmbuild -ba once you have made the small correction advised on the spec file.
That's the main features added, you can see below the changelog for this new release and you can always test and give feed back, report bugs and suggest enhancement on the trac of the R2spec project [1].
The RPMs and sources are available on the git of the R2spec project [2].
Thanks for your attention :-)
[1] https://fedorahosted.org/r2spec [2] https://fedorahosted.org/r2spec/browse
Fedora-r-devel-list mailing list Fedora-r-devel-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-r-devel-list
On Sun, 2008-08-31 at 13:35 +0100, Dan Bolser wrote:
I think the first step would be to build a dummy RPM that includes all the R-libraries that come by default with R. Such things as base, lattice, stats, etc., etc. All these libraries could (?) be rolled into an RPM called R-libs (or something), and then when packaging an R-library that depends on 'stats', for example, the dependency would be satisfied by R-libs... Is that possible?
The R package already does this:
Provides: R-base = %{version} Provides: R-boot = 1.2 Provides: R-class = 7.2 Provides: R-cluster = 1.11.11 Provides: R-codetools = 0.2 Provides: R-datasets = %{version} Provides: R-foreign = 0.8 Provides: R-graphics = %{version} Provides: R-grDevices = %{version} Provides: R-grid = %{version} Provides: R-KernSmooth = 2.22 Provides: R-lattice = 0.17 Provides: R-MASS = 7.2 Provides: R-methods = %{version} Provides: R-mgcv = 1.4 Provides: R-nlme = 3.1 Provides: R-nnet = 7.2 Provides: R-rpart = 3.1 Provides: R-spatial = 7.2 Provides: R-splines = %{version} Provides: R-stats = %{version} Provides: R-stats4 = %{version} Provides: R-survival = 2.34 Provides: R-tcltk = %{version} Provides: R-tools = %{version} Provides: R-utils = %{version} Provides: R-VR = 7.2
%{version} is the version of R, in this case, 2.7.2.
~spot
2008/8/31 Tom spot Callaway tcallawa@redhat.com:
On Sun, 2008-08-31 at 13:35 +0100, Dan Bolser wrote:
I think the first step would be to build a dummy RPM that includes all the R-libraries that come by default with R. Such things as base, lattice, stats, etc., etc. All these libraries could (?) be rolled into an RPM called R-libs (or something), and then when packaging an R-library that depends on 'stats', for example, the dependency would be satisfied by R-libs... Is that possible?
The R package already does this:
Provides: R-base = %{version} Provides: R-boot = 1.2 Provides: R-class = 7.2 Provides: R-cluster = 1.11.11 Provides: R-codetools = 0.2 Provides: R-datasets = %{version} Provides: R-foreign = 0.8 Provides: R-graphics = %{version} Provides: R-grDevices = %{version} Provides: R-grid = %{version} Provides: R-KernSmooth = 2.22 Provides: R-lattice = 0.17 Provides: R-MASS = 7.2 Provides: R-methods = %{version} Provides: R-mgcv = 1.4 Provides: R-nlme = 3.1 Provides: R-nnet = 7.2 Provides: R-rpart = 3.1 Provides: R-spatial = 7.2 Provides: R-splines = %{version} Provides: R-stats = %{version} Provides: R-stats4 = %{version} Provides: R-survival = 2.34 Provides: R-tcltk = %{version} Provides: R-tools = %{version} Provides: R-utils = %{version} Provides: R-VR = 7.2
%{version} is the version of R, in this case, 2.7.2.
That is excellent. Thanks for the info.
Now is there any way to cross check these against what R actually has installed? I am trying to think about ways that the R-installer could be used in combination with the packages... or is the idea to package the whole of CRAN? Where would such a repo be maintained? How would it be kept in sync with CRAN?
Please just point me at the relevant docs if I am asking questions that have been covered before ;-)
Cheers,
Dan.
~spot
Fedora-r-devel-list mailing list Fedora-r-devel-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-r-devel-list
On Sun, 2008-08-31 at 18:12 +0100, Dan Bolser wrote:
Now is there any way to cross check these against what R actually has installed? I am trying to think about ways that the R-installer could be used in combination with the packages... or is the idea to package the whole of CRAN? Where would such a repo be maintained? How would it be kept in sync with CRAN?
Well, I'm certainly not so bored as to want to repackage all of CRAN. :)
I think the safest thing is to query R for what it has installed, and not be concerned about whether it was built manually from CRAN, or provided pre-built by Fedora.
~spot
2008/9/2 Tom spot Callaway tcallawa@redhat.com:
On Sun, 2008-08-31 at 18:12 +0100, Dan Bolser wrote:
Now is there any way to cross check these against what R actually has installed? I am trying to think about ways that the R-installer could be used in combination with the packages... or is the idea to package the whole of CRAN? Where would such a repo be maintained? How would it be kept in sync with CRAN?
Well, I'm certainly not so bored as to want to repackage all of CRAN. :)
I think the safest thing is to query R for what it has installed, and not be concerned about whether it was built manually from CRAN, or provided pre-built by Fedora.
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?
~spot
Fedora-r-devel-list mailing list Fedora-r-devel-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-r-devel-list
On Mon, Sep 15, 2008 at 6:13 AM, Dan Bolser dan.bolser@gmail.com wrote:
2008/9/2 Tom spot Callaway tcallawa@redhat.com:
On Sun, 2008-08-31 at 18:12 +0100, Dan Bolser wrote:
Now is there any way to cross check these against what R actually has installed? I am trying to think about ways that the R-installer could be used in combination with the packages... or is the idea to package the whole of CRAN? Where would such a repo be maintained? How would it be kept in sync with CRAN?
Well, I'm certainly not so bored as to want to repackage all of CRAN. :)
I think the safest thing is to query R for what it has installed, and not be concerned about whether it was built manually from CRAN, or provided pre-built by Fedora.
In researching the possibility of having userland rpm, there was a suggestion that dummy packages be created for the base system rpms, so that dependencies will be resolved against the system versions. This raises the possibility of a tool to create dummy rpm's for packages installed by R. That way, rather than the user having to check dependencies across 2 different package management systems, there could a command to create dummy rpms for manually built CRAN packages. These could be "installed" so they would be used by rpm to resolve dependencies in pre-built Fedora rpms.
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?
With R, users can manually install CRAN package from source to $HOME/R/library... I doubt that can be handled using the system rpm database -- you would need a database owned by each user. Since some sites are moving to a model that separates user applications from the base system, there is a need for packaging that does not require root access simply to maintain the rpm database.
George N. White III wrote: <snip />
In researching the possibility of having userland rpm, there was a suggestion that dummy packages be created for the base system rpms, so that dependencies will be resolved against the system versions. This raises the possibility of a tool to create dummy rpm's for packages installed by R. That way, rather than the user having to check dependencies across 2 different package management systems, there could a command to create dummy rpms for manually built CRAN packages. These could be "installed" so they would be used by rpm to resolve dependencies in pre-built Fedora rpms.
Would make a fake/dummy RPM be any better than directly package the RPM ? I don't think it decrease the amount of work :/
Or we need something that add the entry to rpmdb while we set up a package using R. But then what about the package installed in $HOME/R/library ? Two users will not have the same libraries available while the database will say that the library is installed.
I know I bring more questions than answers here, but I don't what the best solution would be.
Best regards,
Pierre
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.
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.
-- Pat
On Mon, Sep 15, 2008 at 11:46 AM, Patrice Dumas pertusus@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_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.
r-devel@lists.fedoraproject.org
-
Dan Bolser -
George N. White III -
Patrice Dumas -
Pierre-Yves Chibon -
Tom Callaway