macports-base

org/#development.local-repositories). In some cases (e.g. OpenJDK) we would repack binaries, but we prefer building ports from source (on our Buildbot or during install if binaries are not distributable). We could discuss this on macports-dev. Creating a repository on GitHub and writing (un)install instructions is all we need to get started. > https://trac.macports.org/ticket/57950 Our Trac tickets are somewhat neglected, please post on macports-dev if no one responds. If the change is simple, you can also make a pull request which is easier to review and merge. > has there been any work done on making this migration between OS versions less jarring? Yes, but the PR is stalled for now (lack of manpower again). https://github.com/macports/macports-base/pull/56 I haven't experienced these issues myself because I would always reinstall MacPorts after a major macOS upgrade.

e "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 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/... Development of the port command is relatively inactive (severe lack of manpower). 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 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. [1] https://github.com/macports/macports-infrastructure/blob/mas... [2] https://github.com/macports/macports-base/blob/master/src/po...