Re: pkg_chk (and consequently pkg_rolling_replace) confused with PYTHON_VERSION_DEFAULT=33

[David Holland <dholland-pkgtech%netbsd.org@localhost>]

On Sat, Nov 09, 2013 at 08:35:06AM -0500, Greg Troxel wrote:
 > > I don't think any pkgsrc updating method handles non-default
 > > multiversion packages well. Unless you count using pbulk to recompile
 > > everything.
 > >
 > > This came up again somewhere else just a few days ago. I think it
 > > would be a good thing if we could figure out how to make it work.
 > 
 > Agreed.  My unbaked thoughts are:
 > 
 >   1) any package pyNN-foo should be checked for being up to date vs the
 >   same NN, so that it gets updated along the same python version

Yes. I would expect that this already mostly happens, because the NN
is part of the package name; so if you have py26-bozo-1.0 and the
version of py-bozo goes to 1.1, unless it's trying to parse the name
it will consider py27-bozo-1.1 a different package. At least for
handling binary packages.

For building, I think it's sufficient to take the existing MULTI=
field from BUILD_INFO and stuff it on the make command line. That will
at least stop the problem where you try to build py26-bozo and get
py27-bozo.

However, this first really needs to be rolled into pkgsrc's own
depends handling. As far as I recall (this hasn't come up for me
recently but I don't think anyone's fixed it) if you have a package
that sets PYTHON_VERSIONS_ACCEPTED=26 and then depends on py-bozo,
building it without having first explicitly built py26-bozo croaks.
(It builds and installs py-bozo, gets py27-bozo, and then dies because
the package it expected to get didn't appear.)

Also, 'make update' needs to record the MULTI= info and feed it back
in when recompiling. Right now if you try to 'make update' a package
that has non-default multiversion packages depending on it, it goes
blooey.

 >   2) perhaps optionally, perhaps by default, if a package depends on
 >   pyNN-foo that is not the same NN as PYTHON_VERSION_DEFAULT, then that
 >   package should be marked as needing to be rebuilt

I don't think that's going to work; there are packages that require
older versions of Python (that's why we keep so many Python versions
around, and why we have multiversion packages in the first place) and
always recompiling everything involved on every run seems like a bad
idea.

I think instead the method should be to check PYTHON_VERSION_DEFAULT
from the existing package, and if that's different from the current
PYTHON_VERSION_DEFAULT, the new default version of the same package is
installed or built, and the build gets rid of the dependences on the
old package (and/or it's not tagged as installed manually), remove the
old package. This should allow migration to new default versions
without leaving unwanted cruft lying around.

That specifically won't update py26-bozo to py27-bozo unless something
depended on py26-bozo and now wants py27-bozo instead; but I think
that's a feature.

It also requires having a list of FOO_VERSION_DEFAULT variables to
check; I don't think there's currently any way to get one, and it
won't be reliable to munge the MULTI= list of FOO_VERSION_REQD
variables into the corresponding FOO_VERSION_DEFAULT variables because
they aren't all called FOO_VERSION_DEFAULT. So it probably requires
adding something, maybe MULTI_DEFAULTVARS.

-- 
David A. Holland
dholland%netbsd.org@localhost