MacPorts on multiple Macs
Ryan Schmidt
ryandesign at macports.org
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