Re: [Fedora-r-devel-list] Re: R-devel going away
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
José Matos wrote:
On Thursday 23 October 2008 23:08:53 George N. White III wrote:There have always been conflicts between the CRAN package system and Fedora or other linux packaging Guidelines. Users can install CRAN packages without root privileges, but then the search function won't know about the user's packages, and packages that rely on other library (gsl, hdf5, etc) still need -dev RPM's. Linux distros should not be trying to enforce guidelines for mainstream packages with their own robust package management and archive networks.Playing devil's advocate I should remark that first each language is building its own repository and packaging system in a sense we have lots of equivalents of (yum+rpm) for each language (perl, php, python, R, tex, ...).On the other hand for the system to be really useful it must use the least possible denominator (read the dumbest wins- pun intended ;-) ).Instead, they should look for ways to improve support for users who rely on those 3rd party systems. For example: R-base: basic runtime without dev dependencies, for sites that provide binary CRAN packages (e.g., on a shared directory) so users don't need to do compiles. R-core: R-base + -dev dependencies for those who want to install source packages from CRAN (e.g., most individual R users) R-X-sup(plement): -dev dependencies needed to build package X (e.g., R-hdf5-sup requires hdf5-dev for the hdf5 package from CRAN, gsl-dev for gsl, etc.). These aren't strictly necessary, but would serve to link package versions on CRAN with the versions of the support libs in Fed, something that can take some effort (e.g., peeking in the sources) to determine. For sites where users need to ask admins to install libraries, this simplifies the problem of telling the admin which libs to install.I am not sure if this is right path or the right balance.Another possible choice is to expand R2spec in scope and not only create rpm spec files but to discover the different dependencies and how they are solved inside.There is no reason that we can not rebuild the whole CRAN (or almost all of it) automatically.
R2spec  can handles the generation of spec for R-libraries pretty easily, but the spec always needs some revision behind.
However, I had started some time ago a small script to update the spec file when there is a new release of an already package R-library. This might be something that I should develop maybe a bit more now (especially since Bioconductor 2.3 has been released with R 2.8.0)
Should that be included in R2spec or in a separate tool ?
In the long run, linux distros should look at devising ways to capture information from these 3rd party package managers to help resolve dependencies automatically.As everything with free software the survival of the fittest means that this will only happen if there are people interested in spending resources to make this possible.
-- For those who do not know it R2spec https://fedorahosted.org/r2spec Present in Fedora 8,9 and rawhide (10) and in EPEL 4 and 5. -- Regards, Pierre _______________________________________________ Fedora-r-devel-list mailing list Fedora-r-devel-list@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-r-devel-list
[Home] [Fedora Users] [Fedora Legacy List] [Fedora Maintainers] [Fedora Desktop] [Red Hat 9 Bible] [Fedora Bible] [Fedora SELinux] [Big List of Linux Books] [Yosemite News] [Yosemite Photos] [KDE Users] [Fedora Tools]