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