Re: ERROR: No valid Python version

[Greg Troxel <gdt%lexort.com@localhost>]

Chavdar Ivanov <ci4ic4%gmail.com@localhost> writes:

> Yes, it was replacing cmake at the time, which eventually needed libxslt.

In that case your choice is to fix the real issue first, work around
with a large number of -X, or use -k and see what gets done.

>> I don't know what's going on, and would suggest turning  on set -x and
>> tracing the logs to see.
>
> My assumption on duty in these occasions is always that the problem is
> with my local tree and with the occasional messing I do with it; I try
> to avoid bothering the list with these and to find a solution myself;
> I mentioned the issue as I have had it a few times before. One reason
> might be that I started using  'pkg_rr -suv'  recently, before I used
> to use ' -uvk', which, albeit not safe, at least goes through the
> whole process without intervention and usually does the job (but I
> understand why it shouldn't be used). I'll try to trace it.

-s is strict, which means unsafe_depends_strict is used instead of
unsafe_depends.  In theory, the only time unsafe_depends_strict gets set
when unsafe_depends doesn't is when a package is updated from foo-1.2nb3
to foo-1.2nb4, differing only in PKGREVISION.  This is sort of by
definition fixing packaging issues, and should not change the ABI.
Except deciding to install something, changing options, etc. does.
However there are a ton of revbumps.  So is it safe?  Usually.  I really
doubt your pain is related to failure to rebuild an
unsafe_depends_strict that has an ABI change.

If you haven't done it in a while, -s will rebuild a ton of packages,
and this will expose problems that are about rebuilding those.  So it's
not really that -s causes trouble as much as if you invite 1000 people
to a party one of them is going to fall down and hurt themselves.

In this case, if libxslt is out of date, and you gave -u, then libxslt
should get sorted before cmake, and if not there is likely either a
broken pkgdb on your system or a pkg_rr bug.

When this happens to me, usually when doing a manual make replace, I
just go to the eg. libxslt dir after it fails and type 'make replace
clean', which is fast because it was just built and still there.  You
can do this if you don't want to dig into the bug and if this strategy
works, that tends to argue for a pkg_rr bug.