[Fedora-r-devel-list] Re: R-devel going away

[Pierre-Yves]

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 [1] 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