<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"><br></div><div dir="ltr"><br><blockquote type="cite">On Apr 14, 2022, at 07:54, Peter Serocka <peserocka@gmail.com> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"><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></div></div></blockquote><div><br></div><div>Conflicting directory names... that's a tough one.</div><br><div>Sorry, I was thinking of "isolating," as requiring sandbox, jail, container, etc. I believe you mean "organizing."</div><div><br></div><div>Thinking more about upgrading, maybe there's an Xcode version issue? MacPorts requires Xcode's command line tools. Though a newer version of macOS can run older and outdated versions of Xcode, after upgrading the OS, the user will often find Xcode greyed out with the circle with the line through it. Upgrading macOS didn't used to do this, but it apparently does now. There are steps (or tricks) available now to get older Xcode versions working with a newer mismatched macOS version. But I bet that's why port is choking after upgrade: maybe port still works, but the upgrade broke Xcode, so port chokes. A wild guess.</div><div><br></div><div><br></div></body></html>