<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jul 2, 2019 at 8:52 PM Mojca Miklavec <<a href="mailto:mojca@macports.org">mojca@macports.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sun, 30 Jun 2019 at 14:00, Clemens Lang wrote:<br>
><br>
> On Sat, Jun 29, 2019 at 11:58:04PM +0200, Mojca Miklavec wrote:<br>
> > We are approaching the release of 10.15.<br>
> ><br>
> > What are the chances to get the "port migrate" code merged before the<br>
> > end of this summer and before the release of 10.15?<br>
> ><br>
> > If we wait too long, the OS might change sufficiently that the code<br>
> > will stop working one day.<br>
><br>
> The only problem left I currently see is how the code deals with<br>
> variants in non-requested ports. At the moment, only requested ports are<br>
> being reinstalled, but these requested ports might only work correctly<br>
> if non-requested ports are reinstalled with the same variants (which<br>
> might not be the default ones).<br>
<br>
>From this perspective I can imagine other potential problems. Some<br>
ports may declare a different variant or a different set of<br>
dependencies on an earlier OS than the one we would migrate to. On the<br>
new OS we might have different variants available altogether. So we<br>
probably won't have a foolproof solution anyway until the work from<br>
one gsoc before gets merged (correct handling of dependencies and<br>
variants), and even then there will be further issues.<br>
<br>
Even without "migrate" we are currently stuck when we install a port<br>
with default variant X, and then the default variant changes. Without<br>
reinstalling the port you get stuck with the old variant etc.<br>
<br>
So I cannot decide how big of a problem this is compared to the rest<br>
of issues that might arise and prevent users from getting a smooth<br>
upgrade experience.<br>
<br>
Now that you mention this ... probably the only way to reliably test<br>
this would be if we had some "macports simulator" which would "install<br>
the ports" to some chosen prefix without actually building the ports,<br>
only updating port registry. Then you would tell that "macports<br>
simulator" that it's running on a newer OS version, and it would try<br>
to run migrate. This would make it easier to see at least some of the<br>
potential issues (not all), and it would allow one to run various<br>
upgrade scenarios. I don't see anyone implementing that though, and it<br>
wouldn't be a small amount of work either.<br>
<br>
The biggest mystery to me is that if you forget to do something with<br>
MacPorts before you update, you can only run "rm -rf ..."; you cannot<br>
even run "port installed" etc., which would be handy in such<br>
situations. Again, something unrelated.<br>
<br>
> If that were fixed, the code would be good to go from my PoV. Does<br>
> somebody have time to work on this?<br>
<br>
I was wondering if bribing Umesh to finish this would be an option?<br>
Last time I talked to him he maybe wasn't aware of any pending issues.<br>
>From what I remembered you closed a PR, but left a branch somewhere, I<br>
wasn't aware of what was left either.<br>
<br>
Opening the PR again with the notes about what is still needed might help?<br>
Umesh, how realistic would it be for you to finish the work?<br>
If we don't merge it soon, we may just as well end up not merging it<br>
ever, which would be a pity.<br></blockquote><div><br></div><div>I think I can get around to taking a look at the code again and finishing this. I cannot commit to doing it immediately but soon.</div><div><br></div><div>Opening the PR again might help actually.</div><div><br></div><div>- Umesh</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Mojca<br>
</blockquote></div></div>