On Tue, Jul 2, 2019 at 8:52 PM Mojca Miklavec <[email protected]> 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 >
