[RkWard-devel] Gentoo ebuild
Thomas Friedrichsmeier
thomas.friedrichsmeier at ruhr-uni-bochum.de
Thu May 11 09:20:58 UTC 2006
Hi again,
On Thursday 11 May 2006 08:56, Juan Manuel Peralta wrote:
> unfortunately I believe that it won't fix the sandbox violation. Even if
> you instruct R to install the library under ${DESTDIR} you'll still get a
> sandbox violation, because the main cause of it is that R tries to create a
> lock file outside the sandboxed hierachy (I don't remember if it attempts
> to do so under /tmp or under $R_HOME/library...) even if you specify a full
> path to the INSTALL CMD. I first tried to use that approach in my ebuild
> and it always failed. But it appears that the lock file is not used by R
> when building a binary package, so that's why I created a patch that
> creates a binary package and then unpacked it under ${DESTDIR}.
I see. As far as I can see from the INSTALL script, it creates files
under /tmp, but not in the main library tree (unless that's where the package
is installed to). Actually, I reads "/tmp" from the environment varialbe
${TMPDIR}, so it should be possible to redirect these writes to somewhere
below ${DESTDIR}. I'll look into this in more detail later today.
The reason I'd prefer this approach is that R CMD INSTALL is the default
mechanism for installing R packages, and may in the future potentially do
whatever sort of additional magic not contained in R CMD build --binary. So
with a "manual" unpacking we'd run the risk of becoming incompatible with a
future version of R. It may not seem likely, but I've been bitten by similar
changes in R several times, already.
Anyway, I'll keep you posted.
Regards
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20060511/9fa4eee2/attachment.sig>
More information about the Rkward-devel
mailing list