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

Dirk Eddelbuettel edd at debian.org
Wed Mar 14 04:16:03 CET 2007


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



More information about the R-devel mailing list