During Migration to Arm64 mac, should I null out archs='x86_64' from installed ports list?

[chilli.namesake at gmail.com]

> On Apr 14, 2022, at 07:54, Peter Serocka <peserocka at gmail.com> wrote:
> 
> 
> 
>> On Apr 14, 2022, at 13:08, chilli.namesake at gmail.com wrote:
>> 
>> 
>> 
>> 
>> I don't get it. What is stopping MacPorts users that don't use custom prefixes from using network drives? A custom prefix and hierarchy will not isolate anything.  A package manager isn't much of a package manager if it leaves you in dependency hell... MacPorts solved this already just by being a package manager. Port activation/deactivation is not a bug, it's a feature, and really not much of  headache. Upgrading macOS will not do anything to /opt. An architecture change means another, separate distinct system, which will need it's own OS and MacPorts install.
>> 
>> I'm not seeing the fatal problems your solution of custom prefixes hopes to solve. 
> 
> No fatal problems to overcome, just benefits I have been appreciating.
> 
> Network drives were automounted to a different place than /opt; and /opt/local -- being a quite generic name by itself -- was already taken by other stuff in that specific corporate environment :(
> 
> "Isolating" in the sense of keeping e.g. qt-related or rust-related stuff in different trees,
> to adopt different update cycles.
> 
> Again I find side-by-side installations of alternatives are easier to handle than activations, but of cause your miles may vary. Nothing wrong with that.
> 
>> Upgrading macOS will not do anything to /opt
> 
> Well under /opt/local, installed ports usually keep working, but the port command will refuse to run even simple queries and you have to start all over. With a new prefix tree transitions cam be performed gradually; and you keep a fall-back in place. I just happen to like that -- so why not discussing it in the light of possible binary distributions when that suggestion was made? I understand my proposal doesn't resonate too well with you; anyway, thanks a heap for your efforts!
> 

Conflicting directory names... that's a tough one.

Sorry, I was thinking of "isolating," as requiring sandbox, jail, container, etc. I believe you mean "organizing."

Thinking more about upgrading, maybe there's an Xcode version issue? MacPorts requires Xcode's command line tools. Though a newer version of macOS can run older and outdated versions of Xcode, after upgrading the OS, the user will often find Xcode greyed out with the circle with the line through it. Upgrading macOS didn't used to do this, but it apparently does now. There are steps (or tricks) available now to get older Xcode versions working with a newer mismatched macOS version. But I bet that's why port is choking after upgrade: maybe port still works, but the upgrade broke Xcode, so port chokes. A wild guess.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-users/attachments/20220414/ddeb7a8f/attachment.htm>