Why no R in Fedora (was Statistical Package (like Minitab) for Linux)
MSchwartz at MedAnalytics.com
Wed Mar 3 00:32:36 UTC 2004
On Tue, 2004-03-02 at 16:27, Peter L. Hurd wrote:
> Marc Schwartz <MSchwartz at MedAnalytics.com> 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.
More information about the users