FWIW, I have found it useful to install MacPorts under a new prefix with every MacOS/Darwin release (like /opt/macports##).
This offers a soft transition, as installed stuff usually keeps working after OS upgrades. It has even made sense to hack the port command a little bit, to allow plain queries and port deletions in an outphased MacPorts tree (just no updates or new installs). -- Peter > On Apr 13, 2022, at 10:31, Peter Serocka <pesero...@gmail.com> wrote: > > FWIW, I have found it useful to install MacPorts under a new prefix > with every MacOS/Darwin release (like /opt/macports##). > > This offers a soft transition, as installed stuff > usually keeps working after OS upgrades. > > It has even made sense to hack the port command a little bit, > to allow plain queries and port deletions > in an outphased MacPorts tree (just no updates or new installs). > > -- Peter > >> On Apr 12, 2022, at 16:13, Chris Jones <jon...@hep.phy.cam.ac.uk> wrote: >> >> Hi, >> >> Speaking only for myself, I generally suggest *not* using the >> restore_ports.tcl script. When I migrate to a new OS I generate the list of >> installed ports *and* requested ones, and follow the instructions as far as >> wi[ping out my old ports prior to the update. >> >> However, when restoring the ports I prefer to just manually do this. If you >> just open up the list of requested ports, in whatever text reader you >> prefer, its usually a quite short list (much shorter than all installed) and >> its a short job to go through and reinstall by hand whatever you still want. >> When you do this it will not try and preserve the same variants as before, >> unless you actively request them, and I find this a good idea as default >> variant sometimes get updated so just using the same as before is not always >> the best idea. >> >> This is not to say you still will not have issues with the new Arm arch, as >> for sure some ports will have issues with that. But at least you will not >> have issues because of old settings that should no longer be preserved. >> >> Chris >> >> On 12/04/2022 3:10 am, Jim DeLaHunt wrote: >>> Hello, MacPorts folks: >>> I am following the MacPorts wiki "Migration"[1] instructions as I move from >>> a macOS 10.14.6 Mojave machine with an intel CPU to a macOS 13.1 Monterey >>> machine with an arm64 CPU. I got stuck with a bug in the tiff port, which >>> fails during destroot under the +universal variant. I opened a ticket[2] >>> against tiff +universal on arm64, but that is not my question here. >>> I don't know why MacPorts was trying to install tiff with the +universal >>> variant. I am following the Migration instructions. They have me make a >>> list of installed ports using `port -qv installed`. None of these entries >>> mention "requested_variants='+universal'". 91% have an empty string for >>> requested variants. 9% request some other variant. However, two-thirds >>> mention "archs='x86_64'", while the other one-third mention >>> "archs='noarch'", and none have empty strings or some other value for >>> "archs". I use the restore_ports.tcl script to install the ports on the new >>> computer. >>> Here are four representative entries from my list of installed ports: >>> aalib @1.4rc5_5 (active) requested_variants='' platform='darwin 18' >>> archs='x86_64' date='2021-08-30T13:16:05-0700' >>> abcde @2.9.3_1 (active) requested_variants='' platform='darwin 18' >>> archs='noarch' date='2022-01-23T21:52:02-0800' >>> apr-util @1.6.1_2+no_bdb (active) requested_variants='+no_bdb' >>> platform='darwin 18' archs='x86_64' date='2021-08-30T13:16:21-0700' >>> aspell @0.60.8_1 (active) requested_variants='-nls' platform='darwin 18' >>> archs='x86_64' date='2021-08-30T13:34:34-0700' >>> Might the presence of "archs='x86_64'" cause the restore_ports.tcl script >>> to ask for +universal variants on the new computer? >>> Should I perhaps null out the value "x86_64" from the archs entries in my >>> installed ports list? i.e. turn them into "archs='' "? Or should I replace >>> them with the value "arm64"? >>> I don't see any mention in the Migration instructions about modifying >>> "archs" entries when migrating from one architecture to another. >>> [1] <https://trac.macports.org/wiki/Migration> >>> [2] <https://trac.macports.org/ticket/64933>, tiff@4.3.0_0+universal: >>> Failed to destroot tiff, "libtiff-4.pc differs" >>> -- >>> . --Jim DeLaHunt, Vancouver, Canada >