<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Another reality is that a LOT of open-source software has /usr/local embedded in its search for components, both for building and running. I think various other software does too; so for example if anything in Xcode (needed to build other compilers) does, the problem could arise that way  too. macOS itself has at least a few references to /usr/local, AFAIK.<br class=""><div><br class=""></div><div>MacPorts AFAIK tries not to use /usr/local; but the difficulties in entirely preventing that are considerable;  and having something around with possibly incompatible components will cause problems that are beyond what anyone is prepared to assist with.</div><div><br class=""></div><div>Some totally self-written programs could go there, and not conflict, as long as they didn't install libraries, frameworks, or include files similar to those used by some MacPorts port. Some commercial software like Parallels or VirtualBox will want to put a few things there, and that's generally not a problem.  But other open-source packaging follows its own rules, and the conflicts could cause the problem.</div><div><br class=""></div><div>My personal view is that it's worst if that's there while installing or upgrading ports that are compiled locally; that's where really tough problems might result, because something might be built wrong, which moving the conflicting files away later wouldn't fix. I turned off SIP long enough to change /usr/local to a  symlink; so any time I want what the symlink points to out of the way, I just  rename that, and it's no longer visible; usually good enough to do that while building ports, (I would likely have to redo such tinkering after a macOS upgrade, since it tends to want to revert unapproved changes.)</div><div><br class=""></div><div><br class=""></div><div><br class=""><blockquote type="cite" class=""><div class="">On Dec 23, 2019, at 17:30, Michael Newman via macports-users <<a href="mailto:macports-users@lists.macports.org" class="">macports-users@lists.macports.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">On Dec 23, 2019, at 21:06, Ryan Schmidt <<a href="mailto:ryandesign@macports.org" class="">ryandesign@macports.org</a>> wrote:<br class=""><div class=""><blockquote type="cite" class=""><br class="Apple-interchange-newline"><div class=""><span style="caret-color: rgb(0, 0, 0); font-family: Courier; font-size: 24px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">As far as I know, yes it does, by default, which is why, if you install them to their default locations, you should only use one package manager and uninstall the other to prevent conflicts.</span><br style="caret-color: rgb(0, 0, 0); font-family: Courier; font-size: 24px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""></div></blockquote><br class=""></div><div class="">I supposed that in an ideal world where a single package manager had all available packages and where broken packages were fixed quickly, that might work.</div><div class=""><br class=""></div><div class="">Unfortunately, this is not the case.</div><div class=""><br class=""></div><div class="">I have been using ffmpeg from MacPorts daily for several years. It broke with the release of Catalina. A ticket has been filed (59750). But, I can’t wait for it to get fixed. I need it every day. The only alternative I could find was avconv, which MacPorts doesn’t have. I don’t know how long it will be before ffmpeg works again.</div><div class=""><br class=""></div><div class="">However, I do have some experience. I used to use sunwait. It broke. I filed a ticket (51700). It took two years before sunwait was fixed. In the meantime, I had to find an alternative.</div><div class=""><br class=""></div><div class="">I’m not trying to be critical here. I understand the situation. This is all done by volunteers who have way more smarts and ability than I have. </div><div class=""><br class=""></div><div class="">The reality is that people are going to use more than one package manager if the need arises. </div><div class=""><br class=""></div><div class=""><br class=""></div><br class=""></div></div></blockquote></div><br class=""></body></html>