running macports along with homebrew

Ryan Schmidt ryandesign at macports.org
Tue Aug 29 21:24:46 UTC 2017


On Aug 29, 2017, at 07:08, db wrote:

> best practice for running macports along with homebrew

The best practice is not to do that. We don't support it. It can cause you problems that we don't want to spend time investigating, because they wouldn't be problems if you hadn't also used a second package manager.

Using MacPorts trace mode would probably mitigate most of the problems. That's the "-t" flag to MacPorts. It's not the default mode of operation at this time because it incurs a performance penalty (~50%, last time someone mentioned it).


On Aug 29, 2017, at 12:27, Ken Cunningham wrote:

> FYI, it's actually not hard to write a portfile to install a binary, and it's useful in some cases. Here's one I wrote <https://github.com/kencu/LionPorts/blob/master/devel/qt5-qtcreator/Portfile>.
> 
> But MacPorts so far has explicitly stated they are not interested in getting into this line of software package management at present.

A MacPorts port can install a binary, if that's the only way the developers provide the software, and if there's a good reason for it to be in MacPorts, for example other ports depend on it. oracle-instantclient and libxl are libraries provided in binary form, because other ports (such as php modules) link with them. osxfuse and other ports that install kernel extensions do so using a developer-signed binary on Mavericks and later because Mavericks and later don't allow unsigned kernel extensions to be loaded.



More information about the macports-users mailing list