We've had a long-standing issue with the r-base package that complicates
updates. Basically the problem is that each new major version of r-base
stashes its files in a versioned directory within its framework, and
anything that links the R library therefore requires that versioning.
For example:
$ otool -L /sw2/lib/python2.5/site-packages/_rpy2070.so
/sw2/lib/python2.5/site-packages/_rpy2070.so:
/sw2/Library/Frameworks/R.framework/Versions/2.7/Resources/lib/libR.dylib
(compatibility version 2.7.0, current version 2.7.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current
version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 111.1.1)
(which was built against the r-base version from the tracker
https://sourceforge.net/tracker/?func=detail&atid=414256&aid=1955281&group_id=17203
, since I had that installed but not the release version (2.6.0) )
So let's say we updated r-base to 2.8.0. It would install stuff in
%p/Library/Frameworks/R.framework/Versions/2.8 , and then anything that
linked to the older version of libR.dylib wouldn't be able to find it.
Currently only labplot and rpy-py* depend on r-base, so forcing rebuilds
isn't terribly hard (thought labplot takes a while to rebuild). It
would be better to come up with a scheme in which we can leave the
library around for a particular R version (like our standard -shlibs).
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Fink-devel mailing list
[email protected]
http://news.gmane.org/gmane.os.apple.fink.devel
