On Sun 27 May 2018 at 09:17, Eli Schwartz <eschwartz@archlinux.org> wrote:
On 05/27/2018 10:03 AM, Alex Branham wrote:
I doubt anyone is just looking randomly to see which R packages are available, but if they are, the most effective way would be to download https://aur.archlinux.org/packages.gz and use regular expressions to find packages matching the pattern ^r-
It would be nice if the web search interface supported things like this.
Voted, thanks.
# Maintainer: Alex Branham <email-address-removed> _cranname=A3 _cranver=1.0.0 pkgname=r-cran-a3 pkgver=1.0.0
Why is cryanver different from pkgver?
CRAN versions can contain characters that aren't allowed in PKGBUILDS such as hyphens.
Hmm, I think it's more common to use e.g. pkgver=${_pkgver//-/.}, then use _pkgver everywhere where file/directory names are needed (_pkgver or _cranver, either one, obviously _pkgver will be more likely to be used in places that don't actually use cran...)
Less hardcoding, easier to grok the relationship between the two if you set the pkgver from the cranver rather than independently hardcoding it too.
This makes sense. I started out setting pkgver in the R script because I wasn't sure how much I would need to change cranver. I'll look over a few though and see if it's just as easy to set it in the PKGBUILD though.
pkgdesc="Supplies tools for tabulating and analyzing the results of predictive models. The methods employed are applicable to virtually any predictive model and make comparisons between different methodologies straightforward."
pkgdesc should be 80 chars, not 218
Thanks. I'll work on shortening the pkgdesc to around 80 characters.
Yeah, this one will be... problematic, if you're just using upstream descriptions in a generated script, but it's well worth doing correctly (often manually), because the alternative is some fairly ugly pacman -Si output.
Hopefully you can figure out some way that does not require writing all 13K out by hand... though this won't be as much of a problem if you use a whitelist.
Yes, I'm not looking forward to this part :-(
package() { mkdir -p ${pkgdir}/usr/lib/R/library cd ${srcdir} R CMD INSTALL ${_cranname} -l ${pkgdir}/usr/lib/R/library }
This compiles source code into x86_64 ELF executable code, in the package() step?
Is your question here about the architecture? It automatically detects that during R CMD INSTALL.
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.
(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.
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. Thanks again, Alex