[Fedora-r-devel-list] Re: R-devel going away
pingou at pingoured.fr
Fri Oct 24 07:43:19 UTC 2008
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
>> 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
> 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
Present in Fedora 8,9 and rawhide (10) and in EPEL 4 and 5.
More information about the fedora-devel-list