On Sun 27 May 2018 at 09:17, Eli Schwartz <[email protected]> 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
