I have been running MacPorts (and Fink before that) on Intel processors for many years. During the Migration Assistant process yesterday, the /opt directory was moved and a quick test of one or two binaries shows that they still execute.
Nonetheless, it is probably wiser to rebuild the apps in MacPorts. Perhaps delete everything and start over?
Any advice? Thanks.
If you’re using recent MacPorts, you should have the “migrate” subcommand (see port-migrate(1)) which does exactly what you want.
Otherwise you’ll have to list all your installed/requested ports and do a nuke and pave. If you can’t use the port command to do this then dig around in the “software” directory to find all of the ports you have and their variants, then reinstall the ones you need.
Thanks.
Is the Mojave version of MacPorts considered recent?
I also noticed that Migration Assistant created a /User/MacPorts directory – this did not exist in Mojave.
It looks like they’re maintaining support for Mojave, yes, so if you’ve been keeping updated (with port selfupdate) then you should have the migration feature.
And I shouldn’t worry about the extra user directory, I think MA just created the directory to correspond with the system account MacPorts is using. It’s probably empty, so you could just hide it from view and be fine.
It looks like you have what you need to proceed with your migration, but it would have happened faster if you had just gone through the FAQ’s on the MacPorts website or used their e-mail forum to ask anything you still didn’t understand. They are very quick with responses.
I went for the “nuclear” option and removed the entire /opt/local directory because I could not find a record of what I had installed. I started from a clean baseline and will install ports when/if I need them. I think this will satisfy my needs.
Just a quick note for anyone looking for Mac ports of open-source software: I find Homebrew to be generally very well supported and modern, though you do have to keep from cringing at its insistence on overusing the “brewing” metaphor by calling things “casks”, “formulas”, etc.
I had been using Fink for years, but finally got fed up with their feet dragging on supporting macOS Big Sur (!) and later. So this year I switched to Homebrew.
It is a lot easier to use and faster to install packages. And here’s a hint: in at least the case of Regina REXX, installing through Homebrew is actually much better than just downloading and installing the macOS package from the Regina site. It avoids a lot of macOS security errors. *
But I’m with you the terminology. You need a glossary to understand it. For example, a package is a “formula” unless it installs a macOS application, in which case it is a “cask”. Huh? Isn’t beer in a cask also brewed from a formula?
And there’s taps, bottles, kegs, racks, cellars, caskrooms, and tabs. Enough already! We get it, you like beer.
* What I mean is, Regina has a tarball of the compiled macOS programs, that you unarchive into some folder in /etc. This worked until Ventura (or maybe Sonoma), but now if you do that, you get the macOS security prompts like when you try running an application that isn’t notarized. But you get this for the REXX libraries! How do you right-click open and approve a library?
When you install REXX through Homebrew, It Just WorksTM. I’m now going to consider this any time some open source project is delivered without an actual macOS .pkg or drag-and-drop .app.
Brew has its fans, and it’s trendy. And “Casks” are nice.
But I need MacPorts mostly for server software, and I do think it’s “truer” to the spirit of BSD port systems, in being self-contained, in trying to avoid dependencies on the system, and in carefully configuring users and privileges correctly to run software. If you just want some handy CLI tools, or you don’t mind following manual instructions to set up privileged services, then Brew is great. And, of course, being able to install macOS apps is nice.
See also pkgsrc from NetBSD, or Nix. Both are delightful, in their own right.
I ran smack-bang into issues caused by the lazy Darwin24-arm64 builder infrastructure and the C++ headers not properly being removed by the Command Line Tools installers after upgrading my server machine (M2 Pro Mini) direct from Ventura to Sequoia. See details at:
https://trac.macports.org/wiki/SequoiaProblems
Migration in this case totally broke, but unfortunately I wasn’t thinking clearly and not only failed to use the MP snapshots feature, but left it too late for Time Machine to restore a version of the tree that was current (I had updated just before doing the macOS upgrade). The ironic consequence being that I could only roll back the entire tree by restoring an outdated backup which, while outdated, worked just fine.
I do love MacPorts but the strong link between an installed system and the base platform libs, despite the lack of any real compatibility issues, does make it quite vulnerable to this sort of regular crisis. Sigh. But when it works, it’s awesome.