From ripley at stats.ox.ac.uk  Sat Mar 17 11:42:32 2007
From: ripley at stats.ox.ac.uk (Prof Brian Ripley)
Date: Sat, 17 Mar 2007 10:42:32 +0000 (GMT)
Subject: [Rd] Support for noarch packages in /usr/share/R/library
In-Reply-To: <1173816315.15673.6.camel@localhost.localdomain>
References: <1173816315.15673.6.camel@localhost.localdomain>
Message-ID: <Pine.LNX.4.64.0703141253321.18829@gannet.stats.ox.ac.uk>

There is nothing in the R definition of a package to indicate if it is 
architecture-specific or not.  Further, one version of a package might be, 
but an updated version might not (as has just happened with 'ifa').

Thus there are currently no 'noarch' R packages.

[For those who miss the subtleties, the installed versions of both the R 
files and the help files may depend on the OS, as could in principle the 
data files.  You need to read every file to find out.  This is not just 
about whether there is arch-specific compiled code.]

On Tue, 13 Mar 2007, Tom 'spot' Callaway wrote:

> As originally raised here:
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231220
>
> It has been proposed that R should support noarch packages
> in /usr/share/R/library in addition to architecture specific packages
> in /usr/lib/R/library or /usr/lib64/R/library.

R supports libraries anywhere specified by the users, and this can be 
specified at site level.  So this seems to be a non-issue: R always has 
supported packages in /usr/share/R/library.

> For example, the mAr addon doesn't have any architecture specific bits.
> Strictly speaking, the Filesystem Hierarchy Standard says it doesn't
> belong in /usr/lib, but rather, /usr/share.

I don't read it as saying so, but it is so badly written that it is 
subject to many interpretations.

> Ideas on the best way to resolve this would be greatly appreciated.

It really only seems to occur if people want to re-package R packages as 
RPMs and use a single file system for multiple architectures.  For those 
(rare) people, setting the default libraries in (say) 
R_HOME/etc/Renviron.site seems a complete solution.   We could add
${sharedir}/R/library to the default .libPaths(), but it does not seem 
worth adding something that would not be tested regularly and can so 
easily be done by the end user.

-- 
Brian D. Ripley,                  ripley at stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595



[Rd] Support for noarch packages in /usr/share/R/library
Prof Brian Ripley