[aur-general] Packaging all CRAN packages for R

[Alex Branham]

On Sun 27 May 2018 at 09:17, Eli Schwartz <eschwartz at 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.
>
> https://bugs.archlinux.org/task/49099

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