[Rd] what is the current correct repos structure for mac osx binaries?

Simon Urbanek simon.urbanek at r-project.org
Mon Jun 16 20:32:23 CEST 2014


On Jun 16, 2014, at 1:18 PM, Skye Bender-deMoll <skyebend at 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 <skyebend at 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 at r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>> 
>> 
>> 
> 



More information about the R-devel mailing list