Bug 210990

Summary: math/libRmath: Convert to standalone port, Mark Un'BROKEN
Product: Ports & Packages Reporter: Joseph Mingrone <jrm>
Component: Individual Port(s)Assignee: Joseph Mingrone <jrm>
Status: Closed FIXED    
Severity: Affects Only Me CC: bf, imp, riggs, swills
Priority: --- Keywords: patch-ready
Version: LatestFlags: koobs: merge-quarterly?
Hardware: Any   
OS: Any   
See Also: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210866
Description Flags
svn diff to fix math/libRmath jrm: maintainer-approval+

Description Joseph Mingrone freebsd_committer 2016-07-10 21:48:08 UTC
Created attachment 172360 [details]
svn diff to fix math/libRmath

ortlint: OK
testport: OK (poudriere: 9.3-RELEASE-p36, i386,  default options)
testport: OK (poudriere: 9.3-RELEASE-p30, amd64, default options)
testport: OK (poudriere: 10.3-RELEASE,    i386,  default options)
testport: OK (poudriere: 10.3-RELEASE,    amd64, default options)
Comment 1 Thomas Zander freebsd_committer 2016-07-16 13:54:14 UTC
Just a general question: Is it necessary to have this port in the tree? There is no consumer in the ports tree, and I wonder: Are there many users who install this port but not math/R ?
Comment 2 Joseph Mingrone freebsd_committer 2016-07-16 14:02:11 UTC
At this moment, math/R does not install files that math/libRmath does.  Namely, 


This is a good question and it applies for math/libR as well.  I am willing to move the features of math/libR and math/libRmath in to math/R.  Maybe we should ask the old maintainer his thoughts and post on ports@?
Comment 3 Thomas Zander freebsd_committer 2016-07-16 16:58:34 UTC
(In reply to Joseph Mingrone from comment #2)

Good idea. If there is a good reason to keep these ports around, then we should. Can you go ahead and collect the information?
Comment 4 Joseph Mingrone freebsd_committer 2016-07-16 17:05:35 UTC
I posted on ports@.  I'll leave the question open for a week or two and summarize the feedback here.
Comment 5 Thomas Zander freebsd_committer 2016-09-10 05:37:13 UTC
(In reply to Joseph Mingrone from comment #4)

Any news?
Comment 6 Joseph Mingrone freebsd_committer 2016-09-10 15:46:17 UTC
There haven't been any replies.  I'm OK with math/libR being retired.  My only hesitation is about performance.  Here is an excerpt from the R Installation and Administration Manual.

"Flag --enable-R-shlib causes the make process to build R as a dynamic (shared) library, typically called libR.so, and link the main R executable R.bin against that library. This can only be done if all the code (including system libraries) can be compiled into a dynamic library, *** and there may be a performance47 penalty. So you probably only want this if you will be using an application which embeds R. ***"

I was considering turning the shared library off for math/R and having math/rkward-kde4, the only port that I'm aware of that depends on the shared library, depend on math/libR.  The other implication for turning off the shared library, is that all R packages will need to be reinstalled.  If we do turn off the shared library option, I'll clean up and simplify math/libR.

Another argument is that those who want optimal performance can compile the port themselves.
Comment 7 Joseph Mingrone freebsd_committer 2016-09-10 16:21:33 UTC
If we went back to a slave port, I think something as simple as this would work.

CATEGORIES=	math lang

MAINTAINER=	jrm@ftfl.ca
COMMENT=	Shared library installation of math/R


MASTERDIR=	${.CURDIR}/../../math/R


.include "${MASTERDIR}/Makefile"

Then math/R would just have to add something like this.


The R developers have this to say about the shared library performance hit. "We have measured 15-20% on i686 Linux and around 10% on x86_64 Linux."  Is a slave port worth recovering this?
Comment 8 Joseph Mingrone freebsd_committer 2016-09-10 16:27:12 UTC
Sorry for the barrage of emails.  The title here is about math/libRmath, but the discussion switched to math/libR.  In short, no one has replied regarding math/libRmath, so it's clear it can be removed from the tree.  I'll wait for feedback regarding math/libR (math/R-libR).
Comment 9 Thomas Zander freebsd_committer 2017-01-04 07:29:32 UTC
Reassign to submitter (with commit bit now :-) )
Comment 10 Joseph Mingrone freebsd_committer 2017-01-05 16:02:56 UTC
math/libRmath had a cleanup and math/libR has been removed.