pkgsrc-Users archive

[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 <> 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,

Ian Leroux

Home | Main Index | Thread Index | Old Index