[RkWard-devel] Gentoo ebuild

[Juan Manuel Peralta]

Hi!

> the ebuild was contributed by Brian Peterson (braverock at users dot
> sourceforge dot net). See also
> http://sourceforge.net/tracker/index.php?func=detail&aid=1483151&group_id=5
>0231&atid=459009 and
> http://sourceforge.net/tracker/index.php?func=detail&aid=1482468&group_id=5
>0231&atid=459007 . As far as I know, none of the developers has ready access
> to a gentoo system. So for coordination and discussing packaging details
> you might want to contact Brian directly.

I'll see if I can get in contact with him. I made an ebuild for 0.3.6 with 
parts of his ebuild and parts of mine, that might be interesting for him.

> Of course still I'm interested in fixing the source distribution of rkward
> to make it easy and clean to package (see below).

Great!

> If I understand the sandbox violation correctly, it comes from the call to
> R CMD INSTALL, which did not honor the DESTDIR setting to make install.

This is correct, the call to R CMD INSTALL is what's causing the sandbox 
violation... but see bellow...

> Therefore the package always got installed to the main R library tree,
> instead of the corresponding directory in the sandbox (could you confirm,
> the sandbox violation comes from the call to R CMD INSTALL, and only
> that?). In my local source tree I have now added a configure option
> --with-r-libdir to specify the R library tree to install to. In the
> Makefile.am in rpackages, I now have
>
> install:
> 	-${R_HOMEDIR}/bin/R CMD INSTALL -l $(DESTDIR)/$(R_LIBDIR) rkward
>
> (added the -l option). I think with this (to be released in the next
> version) no more patch should be needed.

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}.

> Unfortunately, I can not easily 
> produce a diff ATM, as sourceforge CVS is down (again). Once CVS becomes
> available again, I'll ask you to test whether this works as expected (I
> hope I'll remember to do so). I could also send you the relevant files in
> private mail, if you like (~150K).
>
In any case I will be glad to test the changes that you have made and see how 
they behave during an ebuild emerge in gentoo.

> Thanks a lot for your comments, and please let us know, if there are any
> further issues.
>
Don't mention it.  Oh, and greate work fixing the segfaults! Version 0.3.6 is 
far more stable, at least in my machine, than 0.3.5.

Regards,
Juan