On 2023-02-15 at 14:54:40 UTC-0500 (Wed, 15 Feb 2023 14:54:40 -0500)
André-John Mas <andrejohn....@gmail.com>
is rumored to have said:
Hiya,
What is the current status of co-existence of Brew and MacPorts on the
same machine?
Previously this was meant to be a problem.
It remains problematic. The conflict is intrinsic, and cannot be solved
completely without one of the projects adopting the policies and
practices of the other in a fundamentally incompatible way.
With that baseline understanding, you can use both never (if you are
careful and lucky,) have a problem.
I am asking this question, since I am finding more and more recipes
pointing towards
using Brew, instead of MacPorts.
If you try to use both it will *mostly* work and you may never encounter
a problem, but if you do run into a conflict, it could be very hard to
find a solution.
The underlying problem is that many open source packages have /usr/local
hardcoded into their build, install, or load, such that even if they are
made to live in and use the world under /opt/local (i.e. MacPorts) they
may still look for shared libraries under /usr/local first. If you have
a Brew world under /usr/local, there's a significant chance that if you
build MacPorts packages from source, some configure script will pick
stuff in /usr/local/ to use instead of the /opt/local components. That
may work, until the next upgrade of the relevant packages on one side or
the other.
The latest one I ran into was Vagrant, which indicates how to use Brew
to install, but
nothing for MacPorts:
https://developer.hashicorp.com/vagrant/downloads
Also, there doesn't seem to a version of Vagrant in MacPorts.
If there's a recipe for brew, it shouldn't be terribly hard to create a
port for MacPorts. All it takes is someone willing and able to do the
work of creating the portfile and porting patches as needed.
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
