R devel - Mar 2007 - Support for noarch packages in /usr/share/R/library

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.

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.

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

Thanks in advance,

~spot

Tom,

On 13 March 2007 at 15:05, 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.
| 
| 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.
| 
| Ideas on the best way to resolve this would be greatly appreciated.

[ NB I don't speal for R Core here so take it with a grain of salt... ]

Well, R already allows you to source packages from different
directories. E.g. for Debian, we have long used

edd at basebud:~> grep -B2 R_LIBS /etc/R/Renviron
# edd Apr 2003  Allow local install in /usr/local, also add a directory for
#               Debian packaged CRAN packages, and finally the default dir
R_LIBS=${R_LIBS-'/usr/local/lib/R/site-library:/usr/lib/R/site-library:/usr/lib/R/library'}

which uses 

	/usr/local/lib/R/site-library		'user' stuff
	/usr/lib/R/site-library			debs but not r-recommended
	/usr/lib/R/library			debs from r-recommended

Now, if I wanted to, I guess I could modify our already effectively automated
scripts that build the few r-cran-* Debian packages to

a) detect if they are 'arch' or 'noarch', and 

b) in the case of 'noarch' install into a fourth location

	/usr/share/R/site-library		'noarch' debs 

   provided that R_LIBS has also been updated to look there.  

Conceptually at least, this should work.  Ultimately, the FHS has a valid
point and R Core may decide to eventually support this automagically -- just
as R did move towards some support of /usr/share/R after some prodding
following an initial bug report by a Debian user. 

That said, I think the OP from the bugzilla report you referenec may not be
aware just much a 'one file tree below $R_HOME' view R itself (still)
has,
but that is a different story.

Hoep this helps, Dirk

-- 
Hell, there are no rules here - we're trying to accomplish something. 
                                                  -- Thomas A. Edison

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