tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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

David Holland <> 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.


> 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

Home | Main Index | Thread Index | Old Index