Bug 210990 - math/libRmath: Convert to standalone port, Mark Un'BROKEN
Summary: math/libRmath: Convert to standalone port, Mark Un'BROKEN
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Joseph Mingrone
URL:
Keywords: patch-ready
Depends on:
Blocks:
 
Reported: 2016-07-10 21:48 UTC by Joseph Mingrone
Modified: 2017-01-05 16:02 UTC (History)
4 users (show)

See Also:
koobs: merge-quarterly?


Attachments
svn diff to fix math/libRmath (7.42 KB, patch)
2016-07-10 21:48 UTC, Joseph Mingrone
jrm: maintainer-approval+
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
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, 

lib/libRmath.a
lib/libRmath.so
lib/libRmath.so.%%RMATH_SOVERSION%%.

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.

==========
PORTNAME=	R
CATEGORIES=	math lang
PKGNAMESUFFIX=	-libR

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

LICENSE=	GPLv2

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

OPTIONS_SLAVE=	LIBR

.include "${MASTERDIR}/Makefile"
==========

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

LIBR_CONFLICTS=		R-3.*
LIBR_CONFLICTS_OFF=	R-libR-3.*

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.