David Holland <dholland-pkgtech%netbsd.org@localhost> writes: > On Sat, Nov 09, 2013 at 08:35:06AM -0500, Greg Troxel wrote: > > 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. I dimly remember seeing pkg_chk say that py26-foo-1 was out of date and the new one was py27-foo-1. Similarly, "make show-downlevel" may do things like this. One really needs to pass in the desired version. > 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. That sounds promising. > 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.) Agreed; it seems that the FOO_VERSIONS_ACCEPTED needs to be passed to dependency builds. > > 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. OK - but I think your refinement amounts to "if a package depends on pyNN-foo but NN would not be chosen by the selecetion rules", which sounds good to me. > 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. Right now pkg_rr does not remove automatic=yes packages with no dependencies, but that would work right if the new pyNN-foo is marked automatic by this process. > 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. Agreed. > 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. I agree; having a list of multiversion variables to deal with would be progress, and perhaps their formats should be regularized.
Attachment:
pgpaH0ENs3Iig.pgp
Description: PGP signature