MacPorts on multiple Macs

[Rodolfo Aramayo]

On Sat, Oct 13, 2012 at 10:19 AM, Ryan Schmidt <ryandesign at macports.org> wrote:
>
> 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.

My bad. I meant to say: '/Applications/MacPorts'


>
>> 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.

Which should work fine unless the user account is authenticated by a
central server...But I guess that if the MacPorts user is created
locally it should be OK

>
>> 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.

Amen to that...;;))


--R
>
>> 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..............???
>
>