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