Quoting Dan Nelson <[email protected]> (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
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[email protected]"
