<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Apr 14, 2022, at 13:08, <a href="mailto:chilli.namesake@gmail.com" class="">chilli.namesake@gmail.com</a> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div dir="ltr" class=""><br class=""></div><div dir="ltr" class=""><br class=""></div><div class=""><br style="caret-color: rgb(0, 0, 0);" class=""><span style="caret-color: rgb(0, 0, 0);" class="">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.</span></div><div class=""><span style="caret-color: rgb(0, 0, 0);" class=""><br class=""></span></div><div class=""><font class=""><span style="caret-color: rgb(0, 0, 0);" class="">I'm not seeing the fatal problems your solution of custom prefixes hopes to solve. </span></font></div></div></div></blockquote></div><br class=""><div class="">No fatal problems to overcome, just benefits I have been appreciating.</div><div class=""><br class=""></div><div class="">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 :(</div><div class=""><br class=""></div><div class="">"Isolating" in the sense of keeping e.g. qt-related or rust-related stuff in different trees,</div><div class="">to adopt different update cycles.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div dir="auto" class=""><div class=""><span class="">Upgrading macOS will not do anything to /opt</span></div></div></blockquote><br class=""></div><div class="">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!</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div></body></html>