> On Apr 14, 2022, at 13:08, chilli.names...@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!
