pkgsrc-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: pkg_rolling-replace infinite loop?

"Ian D. Leroux" <> writes:

> On Wed, 11 Aug 2010 23:54 -0400, "Ian D. Leroux" 
> <>
> wrote:
>> 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
>             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

Home | Main Index | Thread Index | Old Index