[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: pkg_rolling-replace infinite loop?
On Wed, 11 Aug 2010 23:54 -0400, "Ian D. Leroux"
> 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
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.
Thanks for the pointers,
Main Index |
Thread Index |