Martin Maechler <maechler at stat.math.ethz.ch> writes:> Well, Dirk has said to have given his last reply on this thread. > I (as a member of R-core) am glad about people like Dirk who > take some of our load and helpfully answer such > questions/reports on R-devel.I am glad too. Thank you. My ultimate goal is to ensure that R works as well on FreeBSD as it does elsewhere. It mostly just works (again, appreciative), but there are a few challenges because some R conventions and some FreeBSD conventions may collide. Dirk Eddelbuettel <edd at debian.org> writes:> Consider eg this:> edd at max:~$ locate Matrix.so > /usr/lib/R/library/Matrix/libs/Matrix.so > /usr/local/lib/R/site-library/Matrix/libs/Matrix.so > /usr/local/lib/R-devel/lib/R/library/Matrix/libs/Matrix.so > edd at max:~$> I have three versions of Matrix.so. And still not problem. The third one > only enters for R-devel, not R. The first two are distinguished by R itself > _by virtue of different paths_ just like Martin and I told you.> And _no_ other program on my system knows about Matrix.so:> edd at max:~$ ldconfig -p | grep Matrix.so > edd at max:~$ ldconfig -p | wc -l > 2814 > edd at max:~$> ldd / ldconfig do NOT know Matrix.so -- as I told you before -- despite the > fact that they know thousands of other things on this (development) machine.For a frequently-updated Debian package repository, I assume you _manually_ bump all the Debian R packages whenever the main R package is upgraded. Is that correct? That is, when a Debian user upgrades the r-base package from, say, version 3.2.5 to 3.3.1, then r-cran-tseries must/should be rebuilt/reinstalled against the new R package? If so, maybe there is something useful we could submit. I will have to study how R uses autotools, because that also seems a bit different than I am used to. I also notice that on Debian you make a soft link of /usr/lib/R/lib/libR.so to /usr/lib/libR.so. Given all that has been discussed, I am unclear why. Thank you for sticking with the thread, Joseph -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 930 bytes Desc: not available URL: <https://stat.ethz.ch/pipermail/r-devel/attachments/20161124/be4da4d3/attachment.bin>
On 24 November 2016 at 22:09, Joseph Mingrone wrote:
| For a frequently-updated Debian package repository, I assume you _manually_
bump
| all the Debian R packages whenever the main R package is upgraded. Is that
| correct? That is, when a Debian user upgrades the r-base package from, say,
| version 3.2.5 to 3.3.1, then r-cran-tseries must/should be rebuilt/reinstalled
| against the new R package? If so, maybe there is something useful we could
You assume that change == breakage. Yet that assumption is baseless.
Which is what someone like Martin (R Core, and "at it" since the 80s
pre-R
and 90s with the almost very beginning of R) and myself (around R since the
late 90s, somewhat involved since the early 00s) keep telling you.
At some point it might appear to be approproiiate for you to actually take
our word for it.
| submit. I will have to study how R uses autotools, because that also seems a
| bit different than I am used to.
|
| I also notice that on Debian you make a soft link of /usr/lib/R/lib/libR.so to
| /usr/lib/libR.so. Given all that has been discussed, I am unclear why.
Well noticed -- yet a stricly personaly reason via two projects I have been
(co-)authoring: littler and RInside. They both "embed" R via libR and
we do
both rpath ("somewhat" verboten by Debian Policy as it hard codes a
path,
hence the alternate of placing it where ldd / ldconfig find it).
But please note that that is _me_ doing this, and the R Core gospel we have
been trying for you to understand still stand: __what you insist is needed
actually is not__.
| Thank you for sticking with the thread,
Sorry for coming through as pedantic but you (and we're now at what, six
posts in and counting?) still start from the wrong (at least outside of the
gilded confines of FreeBSD) premise. It. Just. Works.
Just give us and the unknown-but-sometimes-estimated-to-be-in-the-millions of
R users some credit. What is there __works__. Seriously. Debian folks are
pendantic for technical excellence __and even they have no issue with
per-package and local shared libraries__. Which is what this is. Really.
Dirk
--
http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
Dirk, Dirk Eddelbuettel <edd at debian.org> writes:> You assume that change == breakage. Yet that assumption is baseless.> Which is what someone like Martin (R Core, and "at it" since the 80s pre-R > and 90s with the almost very beginning of R) and myself (around R since the > late 90s, somewhat involved since the early 00s) keep telling you.> At some point it might appear to be approproiiate for you to actually take > our word for it.It is not that I am not taking your word. There are some unique (to me) approaches in R and some of them are subtle. I am also taking criticism from the other side, because, as I said, some conventions collide. When Martin said,> All these libraries "belong to R" and are tied to a specific version of R...I understood that "tied to a specific version of R" meant that (Debian/FreeBSD) R packages should be updated in lock step with R. So, on Debian, changes in the r-core package never necessitate a bump of r-cran-*? In other words, the libR.so interface is guaranteed to be stable across releases?> | I also notice that on Debian you make a soft link of /usr/lib/R/lib/libR.so to > | /usr/lib/libR.so. Given all that has been discussed, I am unclear why.> Well noticed -- yet a stricly personaly reason via two projects I have been > (co-)authoring: littler and RInside. They both "embed" R via libR and we do > both rpath ("somewhat" verboten by Debian Policy as it hard codes a path, > hence the alternate of placing it where ldd / ldconfig find it).> But please note that that is _me_ doing this, and the R Core gospel we have > been trying for you to understand still stand: __what you insist is needed > actually is not__.Understood.> | Thank you for sticking with the thread,> Sorry for coming through as pedantic but you (and we're now at what, six > posts in and counting?) still start from the wrong (at least outside of the > gilded confines of FreeBSD) premise. It. Just. Works.> Just give us and the unknown-but-sometimes-estimated-to-be-in-the-millions of > R users some credit. What is there __works__. Seriously. Debian folks are > pendantic for technical excellence __and even they have no issue with > per-package and local shared libraries__. Which is what this is. Really.Pedantic is fine. I give credit! I would not be investing my (comparatively minuscule) time if I did not appreciate R. I would also not be doing anyone a service if I released a flawed FreeBSD package that did not do the project justice. Joseph -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 930 bytes Desc: not available URL: <https://stat.ethz.ch/pipermail/r-devel/attachments/20161124/770de6ee/attachment.bin>