[MacPorts] Migration modified

[Dan Ports]

On Thu, Jan 21, 2010 at 03:30:29PM -0600, Ryan Schmidt wrote:
> 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.

It wouldn't necessarily be a simple thing to do, but surely it must be
possible. It *would* have to be something aware of dependencies.

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

Obviously, I *can* identify ports I want, but it is silly that I should
have to when this is something that could be automated. I am not
claiming that anything is impossible here, just unnecessarily
difficult.

I have about 500 ports installed. Looking through the full list is a
pretty tedious process.

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

Huh? Of course the system can know which variants I requested --
they're the variants on the ports currently installed, excluding
default (and platform) variants.

Again, I can certainly figure out the list of installed ports with
non-default variants by hand, but why should I have to?

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

Are you suggesting that the solution is that I *should* have the
dependency tree memorized? 

> > 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 do remember the automated process (it was to use upgrade --force, right?),
but I never tried it myself (I upgraded to Snow Leopard relatively
late).

I'm not sure how undeclared dependencies can be considered anything
other than a bug, although gsed etc are an interesting case. autotools
might be another example.

I'm not arguing that uninstalling and reinstalling all ports on an OS
upgrade is a bad idea, especially when things can change so drastically
as the build architecture. What I would like is for MacPorts to give a
little more support in the process -- say, by printing the list of
"port install" commands I'll need to run to get all of my old ports
installed with the same variants.


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

Agreed that this is not the highest priority issue around, but it has
certainly been a rough edge in my experience.

Dan

-- 
Dan R. K. Ports              MIT CSAIL                http://drkp.net/