Not much reason to have */R-cran-* ports

[Rainer Hurling]

Am 20.03.2018 um 21:32 schrieb Yuri:
> On 03/20/18 11:20, Eugene Grosbein wrote:
>> It is a bit funny you are bothered on 250 R-cran-* ports when we have
>> 1908 p5-* ports,
>> 964 py-* ports, 600 rubygem-* ports and 280 hs-* ports in the single
>> ports/devel category.
>>
>> Are you planning to ban and remove p5 ports too? Most of them should
>> be from CPAN.
>> We had BSDPAN for some time even...
> 
> 
> You are missing the key differences:
> 
> 1. Python and perl ports represent individually run software with their
> own executables, when R doesn't. R packages are only useful in the
> context of R, as building blocks of larger R programs only runnable in R
> environment. R packages are much more dependent on environment.
> 
> 
> 2. With python, there is a hope of having all major software pieces in
> ports. With R there is no such hope. There are thousands of individual
> small R packages, while we only have 250 in ports with no hope or reason
> to add another few thousands. Now, if I want to use some R package
> should I look it up in ports and try to port if it is missing? Of course
> not, I will just install it from R. It's much easier this way,
> 
> 
> Yuri
> 

I think, the initial reason for creating R-cran ports was, that several
of them should take care of needed non-R dependencies, like
math/R-cran-sf, math/R-cran-nloptr, math/R-cran-igraph,
databases/R-cran-RMySQL, and many others.

A second reason was, that some of the original R packages have to be
patched to build on FreeBSD, like devel/R-cran-Rcpp,
textproc/R-cran-xml2, security/R-cran-openssl, and others.

Without ports for those, some R packages are not installable and in many
cases needed dependencies are missing.

It seems, we need some (other) mechanism, which should take care of
those R packages.

Regards,
Rainer