port migrate/restore enhancement request

[pietvo (Pieter van Oostrum)]

I did a sudo port migrate after installing a new OS version (Sonoma). However migrate failed because there was a dependency cycle in my ports: graphviz (+pangocairo+rsvg) => librsvg => vala => graphviz. And then all ports depending on these three also fail, which is quite a number.

The solution to break this cycle is to first install graphviz -rsvg, and then vala and librsvg, and finally graphviz +rsvg. However port migrate cannot do this. A solution would have been to install graphviz -rsvg befor the migration, but as I detected this problem after the migration attempt it was too late to do this. Also I couldn't find where the snapshot information was stored, otherwise I might have been able to edit that information.

So I "fixed" it by doing the install as described above, and then running sudo port restore --last. Unfortunately this deactivates everything, and does the check for the cyclic dependency again, so this doesn't solve the problem. I ended up by manually going through the migration/restore log and the installing the failed ports with sudo port install. However, this is tedious and error prone. The idea of port migrate is that everything should go automatically.

Another problem that I can see is when a port requires that another one (or itself) must be deactivated before installing. For example I have sigil and it requires that libzip be deactivated before its installation. With the current migrate you can't do this. And you have no guarantee that migrate or restore wouldn't install libzip before sigil.

So my request is to give port restore an option (e.g. --continue), that does not deactivate the already installed ports and doesn't check dependencies for these. (Actually this is what I had expected it to do.) In this way it is possible to manually correct problems during migration, and then continue with what is left over.

[jmroot (Joshua Root)]

The snapshots are stored in the registry database, and can be edited with sqlite3 in a pinch. There is also as yet unreleased JSON export and import functionality. TBH, if you have figured out which variant you want to disable to break a dependency cycle, it may be easiest to edit the Portfile and temporarily remove or rename the variant.

Programmatically detecting dependency cycles and then systematically toggling variants on and off to try to break them is not impossible, but it would add quite a lot of complexity. There's no guarantee that there is even a possible solution in all cases, and the choice of where exactly to break the cycle would be have to be arbitrary unless the user is consulted, and they may not know either.

All in all, both circular dependencies and build-time conflicts are pretty terrible and it would be far preferable if ports avoided them (however realistic or otherwise that expectation may be…)

[jmroot (Joshua Root)]

The reason for deactivating everything first, BTW, is that some dependencies resolve differently depending on what ports are already active, and dependencies may have changed if you synced your ports since the last restore attempt. The safest approach for avoiding build conflicts would be to deactivate everything that isn't needed before each build. But there is a tradeoff because that results in a huge number of activations and deactivations when you're restoring a lot of ports.

[pietvo (Pieter van Oostrum)]

I am not proposing to let migrate/restore find out how to break dependency cycles. That should be done by the person doing the migrate. In my proposal the default action does not change. Just when this special option is given, then it would essentially do the equivalent of port install <all not yet migrated ports>. Because that is what I did after breaking the dependency cycle and installing the affected ports. Only I had to manually finding out which ports I still had to install, and then I gave the sudo port install command with that list of ports. With my proposal, if the special option is given port restore would just do this for me. It is the responsability of the installing person if this goes correctly, like always.

[pietvo (Pieter van Oostrum)]

An alternative would be if port restore would have an option to give a list of ports that failed to install, in a form that can be used as argument to sudo port install, including the variants of each port as it was before the migration.

[jmroot (Joshua Root)]

I'm not saying no to this, just considering alternatives and pointing out that the problem is a little harder than it sounds.