"Ian D. Leroux" <idleroux%fastmail.fm@localhost> writes: > On Wed, 11 Aug 2010 23:54 -0400, "Ian D. Leroux" > <idleroux%fastmail.fm@localhost> > wrote: >> At Wed, 11 Aug 2010 10:34:00 -0400, >> Greg Troxel wrote: >> > Ian D. Leroux <idleroux%fastmail.fm@localhost> writes: >> > > Any ideas on where I should start looking for an explanation? >> > >> > pkg_rr builds a dependency list that gets tsorted, and rarely something >> > happens that causes that list to get messed up, resulting in an infinite >> > loop. If you want to debug it, I suggest adding 'set -x' to pkg_rr and >> > running again, saving the output. >> >> Thanks, these are exactly the sort of suggestions I was hoping for. >> >> I'm running the instrumented pkg_rr now and will examine the output in >> the morning (when I'm smarter). > > OK, I think I roughly understand what is going on. pkg_rr builds a > dependency list, tsorts it, and then iterates through it looking for the > first package that needs to be rebuilt. Lines 416--420: > > for pkg in $TSORTED; do > if is_member $pkg $REPLACE_TODO; then > break; > fi > done > > If, for some reason, the packages in $REPLACE_TODO don't appear in > $TSORTED, the loop terminates normally (i.e., without ever breaking), > and the last $pkg in $TSORTED gets rebuilt. In my case, the packages in > $REPLACE_TODO were py26-gnupg and py26-setuptools, while $TSORTED > contained py25-gnupg and py25-setuptools, so the last package in my > $TSORTED list (wl-snapshot) just got repeatedly reinstalled; pkg_rr > never finished, because the packages that actually needed rebuilding > never got rebuilt. I manually installed the py26-versions and now > pkg_rolling-replace finishes properly. > > I can pretty easily patch the loop so that it recognizes when it > finished without breaking and exits with an error, but that's a bandaid. > The real fix would be to guarantee that $REPLACE_TODO really is a > subset of $TSORTED. I think you are right. While i see you your point about the correct fix is to preserve the invariant that $REPLACE_TODO is a subset of $TSORTED, I think it's more important that there not be infinite loops. So I would definitely appreciate a tested patch to error out if this case happens, which I think is just a fatal error between the 'fi' and 'done' above. Or is it harder than that?
Attachment:
pgp3gCfWq9lgd.pgp
Description: PGP signature