> On Apr 14, 2022, at 06:45, Peter Serocka <[email protected]> wrote: > > > >> On Apr 14, 2022, at 11: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. >> > > 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.
