Merging "port migrate"?

Mojca Miklavec mojca at
Tue Jul 2 15:21:54 UTC 2019

On Sun, 30 Jun 2019 at 14:00, Clemens Lang wrote:
> On Sat, Jun 29, 2019 at 11:58:04PM +0200, Mojca Miklavec wrote:
> > We are approaching the release of 10.15.
> >
> > What are the chances to get the "port migrate" code merged before the
> > end of this summer and before the release of 10.15?
> >
> > If we wait too long, the OS might change sufficiently that the code
> > will stop working one day.
> The only problem left I currently see is how the code deals with
> variants in non-requested ports. At the moment, only requested ports are
> being reinstalled, but these requested ports might only work correctly
> if non-requested ports are reinstalled with the same variants (which
> might not be the default ones).

>From this perspective I can imagine other potential problems. Some
ports may declare a different variant or a different set of
dependencies on an earlier OS than the one we would migrate to. On the
new OS we might have different variants available altogether. So we
probably won't have a foolproof solution anyway until the work from
one gsoc before gets merged (correct handling of dependencies and
variants), and even then there will be further issues.

Even without "migrate" we are currently stuck when we install a port
with default variant X, and then the default variant changes. Without
reinstalling the port you get stuck with the old variant etc.

So I cannot decide how big of a problem this is compared to the rest
of issues that might arise and prevent users from getting a smooth
upgrade experience.

Now that you mention this ... probably the only way to reliably test
this would be if we had some "macports simulator" which would "install
the ports" to some chosen prefix without actually building the ports,
only updating port registry. Then you would tell that "macports
simulator" that it's running on a newer OS version, and it would try
to run migrate. This would make it easier to see at least some of the
potential issues (not all), and it would allow one to run various
upgrade scenarios. I don't see anyone implementing that though, and it
wouldn't be a small amount of work either.

The biggest mystery to me is that if you forget to do something with
MacPorts before you update, you can only run "rm -rf ..."; you cannot
even run "port installed" etc., which would be handy in such
situations. Again, something unrelated.

> If that were fixed, the code would be good to go from my PoV. Does
> somebody have time to work on this?

I was wondering if bribing Umesh to finish this would be an option?
Last time I talked to him he maybe wasn't aware of any pending issues.
>From what I remembered you closed a PR, but left a branch somewhere, I
wasn't aware of what was left either.

Opening the PR again with the notes about what is still needed might help?
Umesh, how realistic would it be for you to finish the work?
If we don't merge it soon, we may just as well end up not merging it
ever, which would be a pity.


More information about the macports-dev mailing list