Re: pkg_rolling-replace infinite loop?

[Ian D. Leroux <idleroux%fastmail.fm@localhost>]

At Sun, 29 Aug 2010 18:38:49 +0200,
Alan Barrett wrote:
> You may be encountering an old bug, in which the attempt to build
> py25-something actually ends up building py26-something, simply because
> of PYTHON_VERSION_DEFAULT=26.  Then, next time round the loop, pkg_rr
> notices that py25-something is not installed, so it tries again, with
> the same bad result.
> 
> Please try the appended patch, which I have been using for some time.

Although I can't test your patch directly (I fixed the offending
packages by manual intervention, and now I'm having trouble
reproducing the problem), I believe I ran into a different (but
related) behaviour: rather than repeatedly trying to rebuild
py25-something and getting py26-something instead, what I saw was some
part of pkg_rr determining (incorrectly) that py26-something needed
rebuilding.  Since there was no py26-something even installed on the
system, this broke the assumption in pkg_rr that the packages to be
rebuilt appear somewhere in the dependency graph.

Specifically, the dependency graph is built from the output of
pkg_info -N, which lists exactly those packages which are installed or
were installed as dependencies of a currently-installed package.
This, correctly, includes the py25-something packages.  The list of
packages to rebuild, meanwhile, comes from pkg_chk -u -q which is, in
turn, calling pkg_info -Bqa to get a list of package /directories/
like py-something (see pkgdirs_from_installed()) and then converting
those to the package names which /would/ be installed if you ran make
in those directories (pkgdir2pkgname()), which incorrectly yields
py26-something.

At this point I'm starting to wonder whether the question "is foo up
to date" can be well posed, if a given directory category/foo in
pkgsrc can yield multiple differently-named and versioned packages.

Someone please correct me if I'm spouting nonsense.

Ian Leroux