[aur-general] Packaging all CRAN packages for R

[Eli Schwartz]

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

-------------- 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/638270d2/attachment.asc>