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 Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel