Re: changing default python version to 3.11?

[Greg Troxel <gdt%lexort.com@localhost>]

oskar%fessel.org@localhost writes:

>> There have been no comments objecting to moving the default to 3.11
>> after 3.5 weeks and one positive comment.
> I was fine with that expecting nothing serious.

> But on the production machine i run i was updating perl to 5.8 and
> that hit me in the middle because some of the dependent packages
> (which seem to be essentially all ;-)) was dependent on some python
> stuff.  The production ran 3.9 since forever but the new default
> triggered some package builds with 311.  not a problem, i thought.

The default has not actually been changed yet.  See
lang/python/pyversion.mk.  It is merely waiting for someone with the
cycles to deal with revbumping the packages that don't have a pyNN
prefix.

Are you really running pkgsrc-current in production?  I would advise
against that, especially without a staging build machine.

> Until make update bailed out:

'make update' is IMHO asking for trouble.  Sort of off topic, but for a
production machine, I think it's necessary to produce binary packages
without disturbing the production setup, e.g. pbulk or pkg_rr  on some
other setup.

pkg_chk and hence pkg_rr don't deal well with multiversion packages that
aren't the default.  I usually find the set of packages that I want
installed, pkgin uk those and pkgin ar, and then build anew.  Of course
that's on a non-production machine where it doens't matter if it is
temporarily missing things.

> => Tool dependency py311-packaging-[0-9]*: NOT found

You didn't say what needed that and why.
> The following variables will affect the build process of this package,
> py311-packaging-23.1.  Their current value is shown below:
>
>        * PYTHON_VERSION_DEFAULT = 311

Did you change that yourself?

> This is quite reasonable, in that pyhon311 is not installed.  But shouldn’t it be installed if something needs it, like a python311-package?

Yes, and generally this works.

> And yes, this can be fixed manually.  And yes, I am to blame because i
> did not fix pyhton39 as the default for this machine…

I don't follow "did not fix python39 as the default".


I suspect you have odd content in mk.conf, and/or a broken dependency
database.  Overall I recommend (and you are of course welcome to take
each piece advice or not!):

  - deal with production machines by using a quarterly branch
  - deal with production machines by creating binary package sets
  - examine/prune mk.conf
  - pkg_admin rebuild
  - pkg_admin rebuild-tree
  - pkg_admin check
  - install pkgin, look at "pkgin sk|sort", "pkgin uk" things you don't
    intend to have installed, examine "pkgin -n ar|sort", and if  you
    are ok with uninstalling those, "pkgin ar".  When doing upgrades the
    less you have the better and I find software accumulates if I don't
    purge.