Merging "port migrate"?

[Umesh Singla]

On Tue, Jul 2, 2019 at 8:52 PM Mojca Miklavec <mojca at macports.org> wrote:

> 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.
>

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.

Opening the PR again might help actually.

- Umesh


>
> Mojca
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20190714/6b5e1404/attachment.html>