MacPorts on multiple Macs

Ryan Schmidt ryandesign at
Sat Oct 13 08:19:23 PDT 2012

On Oct 13, 2012, at 10:10, Rodolfo Aramayo wrote:

> Buildbots are great and welcome and can produce binaries that can be
> reliable used in different machines of the same 'uname -m'
> architecture

Our binaries are tagged with the architecture. Currently we only have binaries for x86_64.

> BUT MacPorts is more than that
> MacPorts does interact with directories outside '/opt/local' like the
> '/Users/Applications/MacPorts'

The default applications_dir is /Applications/MacPorts (not /Users/Applications/MacPorts). If you've changed applications_dir (or prefix or frameworks_dir) from its default, then MacPorts will not try to use the pre-built binaries.

> And Macport cannot control UIDs which are locally assigned in most cases

My understanding is that it should not matter if the UID of a particular user is different on your machine than it was on the buildbot machine. Things are matched up by username, not user ID.

> A 'normal' user who would just rsync directories within machines
> without taking, for example, UIDs into consideration can potentially
> inadvertently create all sorts of 'invisible' issues

Ah yes now I see what you mean. I'm not familiar enough with rsync to be able to comment on that specifically but I can see how it would be a problem. Which reinforces the idea that you shouldn't try to be tricky and duplicate a MacPorts installation; instead you should install ports on each system as usual.

> and although
> using the rsync parameter "rsync --chmod=ugo=rwX" which assigns the
> same UIDs to files as the target directory, could work, personally I
> have not tested this on 'live' MacPorts deployments
> Unfortunately we do do have ways to testing these 'protocols' without
> having to allocate significant amounts of resources AND time
> I wonder if virtualization could help..............???

More information about the macports-users mailing list