On Tue, 2004-03-02 at 16:27, Peter L. Hurd wrote: > Marc Schwartz <MSchwartz@xxxxxxxxxxxxxxxx> said > | > |On Tue, 2004-03-02 at 14:11, Globe Trotter wrote: > |> On another note, I wonder why this is not included in Fedora. SuSE > |includes it, > |> perhaps because they are European. > | > | > |...Part of the issue is > |the large number of "add-on" packages for R, that are not only on CRAN, > |but on BioConductor and other R related repositories. Trying to > |standardize the various components across multiple locations and for > |multiple versions of RH/FC is a substantial undertaking at this point. > > The fedora rpm provided at the CRAN site contains very few add-on > packages, and is still very use-able. Even just the base & ctest > packages would provide a large amount of functionality. > > Users can easily install.packages() on top of this more stuff from CRAN. > I always seem to end up installing a few packages eg. lineno, or > numline) to RH/Fedora TeTeX installations... I can't see why any heavy > thought has to go into what more or less ought to go into an R package > than is already in the CRAN packages. The above is quite true and that is the present defacto process for R under FC. I do not mean to complicate the perception of the process and my apologies if that is the case. R can be installed via a single RPM and add-on packages (which extend R's substantial base functionality) and updates to them can be installed via a single function within R itself. The base issue is whether or not to make FC RPMS for R available via vehicles other than those that already exist (ie. CRAN) and whether or not to support yum/up2date in some fashion. For example, to make even "base" R part of the FC distribution, it would presumably be done via the the Fedora Extras program (http://fedora.redhat.com/participate/terminology.html), which would entail certain accountabilities to stay abreast of the various requirements placed by the FC leadership. This would include understanding how the existing R updating process may or may not synch with the Extras requirements, if indeed that is an issue. At this point, there is no linkage, since to date they have been independent processes. If it is as simple as submitting semi-annual S/RPMS to Extras as new versions of R are released, that may be a "no-brainer". On the other hand, if there are requirements to periodically submit 'patched' versions of R, based upon certain categories of bug fixes, that may expand the scope of work beyond the available volunteer resources. As one _extreme_ example, the Debian R maintainers (who include several members of "R Core"), have elected to go well beyond providing base R and are providing apt-get-able .debs for most of CRAN, BioConductor and other packages in a central Debian repository. This has required some extensive discussions on their part, including how to differentiate between those packages installed via apt, versus those installed via R's own internal functions. Procedures and policies surrounding possible version control issues, target installation directories and other mechanisms have been discussed at length and resolved within that group. Bear in mind that I am not advocating one approach or another and that I am a firm believer in incremental progress. I have however, offered my assistance to Martyn should he elect to pursue one option or another. It's his call. HTH, Marc Schwartz
