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 <[email protected]> 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:[email protected]
