portupgrade spurious skips

[Alexander Leidinger]

Quoting Dan Nelson <dnelson at allantgroup.com> (from Thu, 26 Feb 2009  
23:57:37 -0600):

> In the last episode (Feb 26), Nate Eldredge said:
>> In the past few months I've noticed a bug in portupgrade.  When I update
>> my ports tree and do `portupgrade -a', often a few ports will be skipped,
>> supposedly because another port on which they depend failed to install.
>> However, the apparently failed port actually did not fail, and if I rerun
>> `portupgrade -a', some of the skipped ports will install successfully
>> without complaint.  After enough iterations I can eventually get all of
>> them.
>>
>> I'd like to file a PR about this, but it's a little bit tricky coming up
>> with a test case, since the behavior depends on having outdated packages
>> installed, and on the dependencies between them.  Moreover, after I run
>> `portupgrade -a' and notice the problem, the state of the installed
>> packages has changed and the same packages aren't skipped the next time.
>> So my question is whether anyone has ideas about how to construct a
>> reasonable test case that could help me make this reproducible and easier
>> to investigate.  Any thoughts?
>
> "me too"..  It seems to happen frequently when doing > 20 or so ports.
> Every week or so I upgrade old ports and don't have problems, but after a
> gnome or xorg update that ends up bumping the portrevision for half my
> installed ports, it always takes three or four "portupgrade -a" loops for
> everything to buid.
>
> If you've got ZFS, you can snapshot your filesystems, and if portupgrade
> fails, roll back to the snapshot and do it again to see if it happens on the
> same port a second time.  Or if you know ruby, you could instrument the code
> that checks for port build errors and see if it's got a bug in it...

There's a more easy solution, pipe the output of portupgrade to a  
logfile. This way you can have a look what happened with the port  
which was reported as broken. Maybe there's a dependency missing, and  
after updating other ports after the failure, this dependency was  
satisfied so that the next run succeeds.

Bye,
Alexander.

-- 
A squeegee by any other name wouldn't sound as funny.

http://www.Leidinger.net    Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org       netchild @ FreeBSD.org  : PGP ID = 72077137