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 06:45, Peter Serocka <peserocka at gmail.com> wrote:
> 
> 
> 
>> On Apr 14, 2022, at 11:48, Ryan Schmidt <ryandesign at macports.org> wrote:
>> 
>>> On Apr 14, 2022, at 04:34, Peter Serocka wrote:
>>> 
>>> Sure. On the other hand -- let me suggest MacPorts to adopt OS/architecture-specific prefixes by default. Transitions will benefit, in particular in cases where "some" ports are troublesome.
>> 
>> I don't think there's any chance of that happening now. MacPorts has used the /opt/local prefix for 20 years and I think you're the first person in that time to suggest changing it. There are many projects out there, and many web pages with documentation, that are already written with that prefix in mind.
>> 
>> Even if we thought it would be a good idea to change it, if we wanted to change it for any existing users, we would have to develop an upgrade strategy for it. And we would have to recompile all of the binary archives we offer.
>> 
>> Migrating to a new OS version or architecture would then become more complicated, as users would need to manually move configuration files and other data from one prefix to another.
>> 
> 
> I have been using MacPort (as non-root) with a custom prefix for about 10 year now, and I have always loved that freedom of choice. Purposes include: using network drives; isolating troublesome ports or dependency hells; trying alternate variants or conflicting ports side by side without deactivating/activating cycles.
> 
> So the prefix has always been "just this string", and MacPorts has been beautifully designed to make it happen. Starting a prefix scheme just when a new OS arrives, no re-compiles of existing binaries will be needed.
> 
> A "meta-select" can easily provide /opt/local as symlink to the desired default tree. Another tiny tool can set up $PATH for users at runtime, providing the bin folders from multiple trees (PATH= ... $(/opt/local/bin/mp_paths) ...)
> 
> 
> Keeping site-specific config files in a tree that basically needs to be wiped out during OS upgrades or architecture changes seems to be fragile and cumbersome to me. Wouldn't one anyway just backup the configs, completely remove /opt/local and start over?
> 


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. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-users/attachments/20220414/077d6cf1/attachment.htm>