A smarter migration behaviour (was Re: usage numbers for macports vs. homebrew?)

Rainer Müller raimue at macports.org
Sun Mar 23 17:19:19 PDT 2014


On 2014-03-22 19:48, Davor Cubranic wrote:
> The amount of traffic to this list that comes down to “you need to run the migration steps from the [Migration] page” is astounding, and it must be a real drain on the time of those who by now must have answered hundreds of such questions.
> 
> It seems to me like we could go a long way toward solving the problem by:
> 
> 1. saving at install time the output of `uname -r` (OS release) into a file in /opt/local/etc/macports/
> 2. every time `port` is run, compare the stored with the current value and stop with an error message if they differ (or more likely if they differ in more than the patch level)

You actually describe what is already coming with the next release:
http://trac.macports.org/changeset/113478

> The error message could direct the user to the Migration page. (Even better if we had a new `port` action to perform the migration steps automatically, even if it wasn’t particularly picky whether a port is being reinstalled because it was requested or simply active at the time of the migration.)

Doing the migration automatically is difficult, because you first have
to remove all ports for clean builds and only then start installing the
previous set of ports.

What would be the strategy for a resume if any port fails to install?
What if the user gives up at some point, never wants to complete the
migration, and starts installing unrelated ports?

We are already going too far into a development discussion in this
thread for the users mailing list, so I'll stop at this point.

Rainer


More information about the macports-users mailing list