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

[Peter Serocka]

app bundles produced by Xcode are much more "controlled" than usual packages that use all kinds of build/make tools... It is virtually impossible to impose the use of @loader_path from the "top" level where MacPorts is operating...

> On Apr 14, 2022, at 11:57, Richard L. Hamilton <rlhamil at smart.net> wrote:
> 
> Would use of @loader_path as in @loader_path/../lib or whatever when linking binaries (and something similar for linking between libraries within MacPorts) not be a big part of  making it so the executables and libraries didn't embed where the tree lived? There would doubtless be other changes to make it possible  to move /opt/local without breaking pre-built binaries, but that might be a big part of  it. And it could be started one port at a time, long before everything needed to be done to make that possible.
> 
> Not sure how executables and frameworks within app bundles in e.g. /Applications/MacPorts could be handled with that.
> 
>> On Apr 14, 2022, at 05:48, Ryan Schmidt <ryandesign at macports.org <mailto: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.
>> 
>> 
> 
> -- 
> eMail:				mailto:rlhamil at smart.net <mailto:rlhamil at smart.net>
> 
> 
> 
> 

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