Disclaimer: I'm a MacPorts committer. > MacPorts almost always builds packages from source Many packages in MacPorts (including LLVM) have pre-built binaries

Disclaimer: I'm a MacPorts committer. > MacPorts almost always builds packages from source Many packages in MacPorts (including LLVM) have pre-built binaries available from https://packages.macports.org/ https://packages.macports.org/ and its mirrors for macOS releases ranging from Mac OS X 10.5 to macOS 10.14. But if a port is considered not distributable because of its restrictive license or license conflicts with dependencies, binaries will not be uploaded to our official mirror so users have to build it from source. We don't provide official binaries for non-default variants or alternative prefix (the default is /opt/local) either, but organizations using MacPorts can set up private mirrors with custom ports and binaries. port_binary_distributable.tcl[1] describes the license conflicts. e.g. "git" is not distributable because its license "gpl" conflicts with license "OpenSSL" of dependency "openssl". > MacPorts seems to be a bit lacking in manpower (which makes things takes slightly longer than I would have expected) Yes, we need more contributors and committers to maintain the large collection of ports we have. Our ports are more often outdated than Homebrew because of this and our maintainer policy. We are also seeking for ways to improve our developer experience, e.g. https://github.com/macports/macports-base/pull/120 https://github.com/macports/macports-base/pull/120 which automates updating checksums in the Portfile. > The lack of color, as well as somewhat more cluttered and less relevant output, makes it a bit less pleasant to work with. We talked about this in a meeting last year, but it hasn't been implemented yet. https://trac.macports.org/wiki/Meetings/MacPortsMeeting2018/UserExperience https://trac.macports.org/wiki/Meetings/MacPortsMeeting2018/... Development of the port command is relatively inactive (severe lack of manpower). https://github.com/macports/macports-base/commits/master https://github.com/macports/macports-base/commits/master > MacPorts will set up its own tools in isolation from those provided by the system Its own versions of libraries, to be exact. See https://trac.macports.org/wiki/FAQ#syslibs https://trac.macports.org/wiki/FAQ#syslibs for more background on this. > builds run in “sandboxes” under the macports user, where attempts to access files outside of the build directory–which includes system tools–are intercepted and blocked It will block writing files outside of directories specified in portsandbox.tcl[2], but using (reading and executing) system tools is allowed. For example, most ports are built with the compiler from Xcode. > The upside is that this approach is significantly more contained, which makes it easier to manage and more likely to continue working as macOS changes under it. Yes, but we recommend users upgrading to a new major release of macOS reinstall MacPorts and all ports because things could still break. We have a migration guide here: https://trac.macports.org/wiki/Migration https://trac.macports.org/wiki/Migration. [1] https://github.com/macports/macports-infrastructure/blob/master/jobs/port_binary_distributable.tcl https://github.com/macports/macports-infrastructure/blob/mas... [2] https://github.com/macports/macports-base/blob/master/src/port1.0/portsandbox.tcl https://github.com/macports/macports-base/blob/master/src/po...