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 <dholland-pkgtech%netbsd.org@localhost> writes:

> On Fri, Nov 08, 2013 at 04:56:14PM +0100, Richard PALO wrote:
>  > Okay, seems pkg_chk is terribly confused when mk.conf contains:
>  > 
>  > PYTHON_VERSION_DEFAULT=    33
>  > 
>  > and, for example, python-27 modules are installed (via meta-pkgs/gnome).
>
> 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

  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

With just (1), pkg_chk (and hence pkg_rr) will often do what people
want, or at least be closer.   Point (2) will be needed to force
rebuilding when python version changes but the python dependencies of a
package hasn't needed to be rebuilt.

I suspect (1) in pkg_chk is not that hard.  I dimly remember trying to
do it, or that someone sent a patch.

Attachment: pgpCZ5NXNz4_P.pgp
Description: PGP signature



Home | Main Index | Thread Index | Old Index