[aur-general] Packaging all CRAN packages for R

[Eli Schwartz]

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

>> The issue is that you're supposed to build during build(), which occurs
>> out of fakeroot and makes the --repackage option make sense (it assumes
>> you already built during build, and just repackages the results, which
>> should result in completely identical contents).
> 
> I'm not sure whether this is possible or not but I'll look into it.

I'm sure it's possible, even if you need to cp it over, but most such
tooling has both a "build" and an "install" command. The latter usually
invokes the former internally.

This is e.g. the case for both traditional Makefiles, and for python's
setuptools. I'm fairly sure the same thing applies by ruby gems. Perl
modules IIRC generate Makefiles which follow this semantic. Golang
doesn't handle installation at all....

-- 
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/20180527/59840e5f/attachment.asc>