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 on 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.
I have been putting off this task but finally did the migrate option. A big problem was that it could not rebuild some gcc stuff that was older–perhaps unsupported–versions. When I tried to run some software that I had compiled years ago with gcc and g77 it failed because of missing libraries.
So I removed the recently updated /opt/local directory and un-tarred the archive I had made a few hours earlier. Everything works again.
It will eventually all break when Rosetta goes away but maybe I won’t care by then. 
I’m a bit concerned about this myself. I doubt I won’t care at all about some of the legacy stuff breaking when 27 comes out and Rosetta is no more.
My 26.4.1 presently only complains about my old Office 2016 — updating that to a native version is trivial. I’ll do that when I absolutely have to. All my other GUI stuff has already been nativized.
I’m more concerned about all the old Intel CLI code hidden away deep somewhere to which 26.4.1 will never alert me and, I’m afraid, 27 will instantly break (assuming the “for legacy games” Rosetta stump Apple keeps mentioning won’t magically fix these kinds of tools). The build I have of all my old TeX and ImageMagick related stuff and all their myriads of little helper apps that I use all the time (say, something as primitive but crucial as epstopdf), but have no recollection of how I installed it and what was required at the time to get it to compile. If high-level GUI tools (say, something like TeXShop) start failing because underlying little helpers no longer work, that will be truly painful. I have no desire to dig in and “figure it out”, I’m too busy for that these days. I just want my old stuff that works fine to this day to continue to run. 
At the same time I’m under no illusion, you can only buy some time, but 27 is coming, Rosetta is going, and we will need to adapt. I guess I’m just hoping there will be a cheap path of least resistance opening up somewhere ahead. 
Solely based on your posts here, aren’t you covered by a site license for Office? Or do you prefer/need Office 2016?