[MacPorts] Migration modified

[Ryan Schmidt]

On Jan 21, 2010, at 15:06, Dan Ports wrote:

> I'll take your word on this particular shell script (I haven't looked
> at it) -- but I think that such a script, if done right, would be a
> great thing to have.

No doubt. But I claim there isn't a way to do such a script properly. Well, maybe there is, with proper hooks into the MacPorts dependency architecture, but this 20-line shell script doesn't do that.


> When I upgraded to Snow Leopard, I found the migration process about as
> far from user-friendly as possible. Aside from the (understandable)
> need to rebuild everything, the instructions weren't easy to follow
> with a lot of ports installed:
> 
> - what are the ports I actually want to use vs dependencies? Easy to
>   miss some when picking them out of a list of hundreds of installed
>   ports.

Look at each port in the list. Is it specifically something you want? For example, when I see "apache2" my brain says "A-ha! That's the Apache web server. I am a web developer and I use this every day. I'd better reinstall that." Whereas when I see "apr-util" my brain might say "I have no idea what that is" and I wouldn't install it. It happens to be an apache2 dependency so it would get reinstalled anyway. But a port might also be something I no longer need.


> - what are the non-default variants I specified? I wound up searching
>   for '+'s to find them, but that also matches +darwin, etc.

Only you can know which variants you requested when installing a port. Request the same variants again. Or consult "port variants" to see all the variants that are available for a port. Maybe the variant descriptions will jog your memory.


> - what order to install them? I don't know the entire dependency tree
>   offhand...

Agreed, this point in the migration instructions is vague, IMHO deliberately so. It is a rather big problem for the user to unravel. "port deps" and the "port-rdeps" script are tools that can be used to learn the dependency tree.

A partial solution is for port authors to get rid of variants wherever possible and move them to separate ports. Another good idea is for ports to check that the required variants of their dependencies are installed. But when port authors have not taken these steps, users must watch out for these issues on their own.


> These seem like they'd be comparatively easy to track/compute
> programatically, especially if someday port can keep track of what's
> installed by explicit request vs dependencies.

You may recall we used to have an automated process documented in the wiki, around the time Snow Leopard was released. (Or maybe that was before your involvement in MacPorts.) But there were so many cases where it failed, because ports did not declare all their dependencies. And I don't even think the ports are wrong in the way they're not declaring them. For example, most ports use autoconf, and most autoconf configure scripts will look for standard utilities, like grep, sed, etc., but most ports don't declare dependencies on the grep or gsed ports because the versions of grep and sed provided by Mac OS X in /usr/bin work fine, and in some cases because the software in question doesn't even care to use those utilities (autoconf just checks for them anyway). But if the user had the grep or gsed ports installed, they would usually fail in a migration scenario, because they depend on gettext. So you rebuild gettext so it's x86_64, and then grep and gsed break because they're i386 and can't link with an x86_64 library. So our instructions were changed to uninstall grep and gsed first. But additional cases like this kept cropping up and it became a support nightmare so the instructions were removed entirely, leaving only the manual method, which is inconvenient but at least it always works.


> I realize that this is probably an issue of time rather than anything
> else, but I just wanted to throw my experiences out there. Perhaps
> someday I'll actually find time to do something about it.

IMHO it's an issue of this being a situation that a user will encounter only once every few years, when they upgrade their OS. There are much more frequent tasks the user will perform with MacPorts, and we have plenty of improvements to make in these areas that will more greatly benefit users.

But certainly, if someone were to come up with an automated rebuild solution for OS migrations that actually works and implement it properly in MacPorts, we would be happy to have it.