[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: pkg_rolling-replace infinite loop?
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
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.
Main Index |
Thread Index |