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.
https://bugs.archlinux.org/task/49099
This would find the regardless of whether they mentioned cran, and in a highly effective manner.
Footnotes: [1] https://github.com/jabranham/r-cran-pkgbuilds/blob/master/gen-R-PKGBUILDS.R [2]
# 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.
pkgrel=1 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.
url="https://cran.r-project.org/web/packages/${_cranname}/index.html" arch=('x86_64') license=('GPL') depends=('r-cran-xtable' 'r-cran-pbapply')
optdepends=('r-cran-randomforest' 'r-cran-e1071')
source=("https://cran.r-project.org/src/contrib/${_cranname}_${_cranver}.tar.gz") md5sums=('027ebdd8affce8f0effaecfcd5f5ade2') 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". (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.) 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).
Thank you very much for the feedback, Eli. I don't have a ton of experience writing PKGBUILDs so this was very helpful!
No problem, that's what we're here for. :p -- Eli Schwartz Bug Wrangler and Trusted User