[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
new pkg_rr to semi-avoid python version lossage, recording python versions
I looked at pkg_chk this morning, and concluded that long-term it's
probably best to reimplement the "for all installed packages, see if
they are out of date" logic, as pkg_chk is doing much more than pkg_rr
As a workaround, I modified pkg_rolling-replace to ignore lines from
pkg_chk that containg "missing". This is hacky, but if you've been
unable to get pkg_rr to run, updating to 0.24.7 and using "-uvk" will
likely work better for you. I am running it now on a netbsd-8 box that
previously had 2019Q1 and hence PYTHON_VERSION_DEFAULT of 27.
My tentative plan is:
add a function to take a PKGNAME/PKGPATH, and determine any other
variables to be set when building, like _PYTHON_VERSION (or something
better that has that effect), extensible to other multiversion
add a switch to pkg_rr to iterate over the installed packages, and for
each figure out if it needs updating given any multiversion settings.
If so, set the mismatch variable on the package.
Change the main loop to use the mismatch variable instead of looking
for mismatches. Perhaps drop the use of -u; if you don't want that,
don't set the variables. Perhaps have -u mean 'set the mismatch
variables", so pkg_rr -u does what it used to.
I wonder why PYTHON_VERSION or similar isn't recorded as a variable in
the binary package. Is that just because it never occured to people, or
is there a reason not to? Which variable should be recorded? It would
be nice if the recorded variable could be set to force the same version
of a multiversion package.
Main Index |
Thread Index |