[aur-general] Packaging all CRAN packages for R

[Eli Schwartz]

On 05/27/2018 12:15 PM, Eli Schwartz wrote:
> On 05/27/2018 11:25 AM, Alex Branham wrote:
>>> No, I assume that all cran packages are ELF executable code, unlike how
>>> ruby or python can be interpreted scripts marked as "any".
>>
>> R packages do not usually (ever? need to check...) produce executable
>> files. R CMD INSTALL copies over the package to a library (AKA a
>> directory. R's term for where packages live on your system). In the
>> latest version of R (3.5.0), they've also started byte compiling it by
>> default.
> 
> Either it is architecture-dependent, or it's an "any" package. I've
> never used R, but I've seen people complaining whenever gcc updates,
> that their AUR packages or things installed to $HOME, are linked against
> old versions of libgfortran.so -- well, usually they complain that R
> itself is linked that way, but the answer we give is always "recompile
> your stuff against the current version."
> 
>>> (In those cases, well, quarry has a function to detect whether the
>>> package contains native extensions, and sets the arch=() of the
>>> generated PKGBUILD as appropriate.)
>>
>> Is this something I need to worry about since Arch only supports x86_64
>> now? So far I've just been setting
>>
>> arch=('x86_64')
>>
>> in the PKGBUILDS.
> 
> If it works on x86_64, it probably works on i686 too, and possibly
> aarch64 users will crave it as well. There's no official policy saying
> you must support that in AUR packages, but OTOH there's no rule saying
> you cannot, if you the maintainer feel comfortable claiming support.
> 
> Either way, I'd encourage your tool to be flexible enough to support
> configurable arch specification.
> 
> ...
> 
> It is, however, a rule that packages which are "build once, run on any
> CPU architecture" should specify "any" (which is the truth), not
> "x86_64" (which is not the truth).

So, I looked into this a bit.

https://cran.r-project.org/doc/manuals/r-devel/R-exts.html#The-DESCRIPTION-file

Looks like the rule is, if NeedsCompilation = yes, then the package
contains C or Fortran code which must be compiled into an ELF library foo.so
In this case, the PKGBUILD should specify arch=('x86_64') and
additionally any other architectures you feel comfortable supporting in
the AUR package.

In the case where NeedsCompilation = no, then the package contains only
R code which is byte-compiled, but can run on any architecture and
should therefore specify arch=('any')

-- 
Eli Schwartz
Bug Wrangler and Trusted User

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/aur-general/attachments/20180530/00cd60ce/attachment.asc>