Date: Fri, 27 Feb 2009 13:19:31 +0100 From: Alexander Leidinger <Alexander@Leidinger.net> To: Dan Nelson <dnelson@allantgroup.com> Cc: Nate Eldredge <neldredge@math.ucsd.edu>, freebsd-hackers@freebsd.org Subject: Re: portupgrade spurious skips Message-ID: <20090227131931.18306giseysouk8w@webmail.leidinger.net> In-Reply-To: <20090227055737.GF45976@dan.emsphone.com> References: <Pine.GSO.4.64.0902262116220.642@zeno.ucsd.edu> <20090227055737.GF45976@dan.emsphone.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting Dan Nelson <dnelson@allantgroup.com> (from Thu, 26 Feb 2009 =20 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 t= he > same port a second time. Or if you know ruby, you could instrument the co= de > 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 =20 logfile. This way you can have a look what happened with the port =20 which was reported as broken. Maybe there's a dependency missing, and =20 after updating other ports after the failure, this dependency was =20 satisfied so that the next run succeeds. Bye, Alexander. --=20 A squeegee by any other name wouldn't sound as funny. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090227131931.18306giseysouk8w>