On Jun 16, 2014, at 1:18 PM, Skye Bender-deMoll <skyeb...@skyeome.net> wrote:
> Dear R-devel, > > Apologies for the confusing typo in the reported paths my previous question, > thanks to Simon for providing the answer that the default repository type on > the mac is now "mac.binary.mavericks" not "mac.binary" as the docs for > install.packages state. > That is incorrect. The default varies by the distribution you use. For the "regular" binary based on 10.6+ it is "mac.binary". For the special Mavericks distribution it is "mac.binary.mavericks". > Perhaps the docs for install packages could be updated something like: > > > ... > type character, indicating the type of package to download and install > > Possible values are (currently) "source", "mac.binary.BUILD_NAME" and > "win.binary". The BUILD_NAME on OSX is determined internally by ???. > ... > > > I'm still not quite clear how the CRAN-like repository should be structured > for OSX. CRAN seems to include .tgz packages in both > > http://cran.r-project.org/bin/macosx/contrib/3.1/ > > and > > http://cran.r-project.org/bin/macosx/mavericks/contrib/3.1/ > > The directory contents are not identical, but both include packages built as > recently as today. Is bin/macosx/contrib/3.1/ a snowleopard build? Do I > need to maintain two directories as well? > > It seems like if I put my packages in > > http://foo/bin/macosx/contrib/3.1/ > > the mavericks machines won't find them. But if I put the packages in > > http://foo/bin/macosx/mavericks/contrib/3.1/ > > people with the snowleopard build wont find them. Perhaps this is the > desired behavior if the mavericks binaries are not snowleopard compatible? > Yes, Mavericks build is incompatible with the Snow Leopard build, that's why there are two separate distributions and two separate repositories. Cheers, Simon > thanks again for your help, > -skye > > > > > > On 06/13/2014 05:22 PM, Simon Urbanek wrote: >> >> On Jun 13, 2014, at 5:41 PM, Skye Bender-deMoll <skyeb...@skyeome.net> wrote: >> >>> Dear R-developers, >>> >>> As part of our package building process, we maintain internal CRAN-like >>> repositories of our packages. This has worked pretty well, but we are >>> running into issues with R 3.1 and OSX mavericks. >>> >>> Specifically, machines with osx mavericks seem to, by default, expect >>> packages to be located under a 'mavericks' sub-directory, but this is not >>> the location reported when generating a mac.binary appropriate contrib url. >>> >>>> contrib.url('foo') >>> [1] "foo/bin/macosx/mavericks/contrib/3.1/" >>> >>> >>> If I ask where the mac binaries are on a linux machine (AND on mac >>> mavericks machines) I get >>> >>>> contrib.url('foo',type='mac.binary') >>> [1] "foo/bin/macosx/mavericks/contrib/3.1/" >>> >> >> I don't think that is true. On all machines (Linux, OS X, ...) I get >> >>> contrib.url('foo', type='mac.binary') >> [1] "foo/bin/macosx/contrib/3.1" >> >> >> Note that the type for the mavericks build is "mac.binary.mavericks", so on >> all machines you also get >> >>> contrib.url('foo',type='mac.binary.mavericks') >> [1] "foo/bin/macosx/mavericks/contrib/3.1" >> >> The only difference are the defaults for pkgType - they differ by the build, >> but the repo structure is fixed and consistent across all platforms. >> >> Cheers, >> Simon >> >> >>> >>> But the OSX machine gives an error and fails to locate the packages if they >>> are located at foo/bin/macosx/contrib/3.1/ >>> >>> So where are the mac binaries supposed to located in a CRAN-like repository >>> so that they can be installed on a mac with the default install command? >>> And is there a way for a non-mac machine (i.e. our linux deploy server) to >>> determine that directory other than contrib.url(,type='mac.binary) ? >>> >>> thanks for your help, >>> -skye >>> >>> ______________________________________________ >>> R-devel@r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-devel >>> >> >> > ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
