Re: changing default python version to 3.11?

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

oskar%fessel.org@localhost writes:

>> 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.
>
> As noted later by you, i wasn’t quite explicitly saying, that I changed 
> the default on the machine in question.  sorry for that

Thanks - it's totally fine for you to change it locally but I wanted to
make sure we were all having a common understanding of what was going
on.

>>> => Tool dependency py311-packaging-[0-9]*: NOT found
>> 
>> You didn't say what needed that and why.
>
> Sorry, that was because of perl update to 5.8 was not handled by pkg_rr on that machine without stopping 
> at every package „another version is installed“…

pkg_rr should choose perl before p5-foo.  Generally, while it's
reasonable to run with -k and then pick up the pieces, when pkg_rr calls
make replace, and that fails, you need to stop and figure out why and
work through it and then continue.

With the perl update to 5.38, my memory is that it just worked (perl
from 5.36 to 5.38 and then all p5-* packages unsafe_depends).

> The package that explicitly had py311-<somthing> as a tool dependency was a2ps, which as rebuilt because of perl.

You said explicitly, but I doubt the Makefile has py311 in it.  if a2ps
were rebuilt ("make replace" succeeded), that would be in the past.  So
something else must be going on.  Again I suggest using pkgin sk/uk/ar
to prune everything you don't want; the less that is there the less
trouble will happen.  Then you can look at the first trouble and dig in.

>>> 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.
>
> in this case obviously not.

SO instead of just saying it doesn't, you should remove all work dirs
and go to make replace in the first package chosen by pkg_rr and trace
what happens, and then start running make show-depends etc. in the
bottommost/failing package, and look up how to tell it to show tool and
build depends, and ask about that specific micro problem.

> I forgot the mantra „Do not build with flexible settings for production“.
> I should not have changed PYTHON_VERSION_DEFAULT...

It's fine to change it.  But if you do you really should rebuild
everything, as in rm/add any "pkgin sk" pyX-foo that is not 311, and
prune any remaining.  Not a rule; just my advice.

> I cannot do that while exposed to the internet.  As soon as a relevant security issue comes up, i feel compelled to fix it.
> When pkgsrc-current already has a fix, that works for me.

OK, but it's quite feasible to basically do your own pullups and mostly
run the branch.  pkgsrc head is sometimes troubled and you might end up
having a non-working system for days.  If you are going to run pkgsrc
head you *really* need a staging server.

>> - pkg_admin check
> i don’t know if that does something more useful than what i already have in place with beefed up tripwire.

I don't either, but run it anyway, and see what it prints out and think
about it, instead of deciding you don't need to.    It checks that the
manifest (PLIST) of each package matches the filesystem.  Sometimes when
people install two copies of something  and remove one, the pkg tools
think things are installed and they aren't.  Those situations show up
loudly with pkg_admin check.  There is no downside to running it other
than it takes a few minutes.

>> - 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.
> i use pkgin on my other machines but switched back to pkg_* for this one.
> Don’t know why, it just feels more controllable - but as you can see, this 
> may not be really true.

You can use sk/uk/ar even if you are building from source.  And you can
create a summary from your own set of binaries.  In the binary package
dir

  pkgsum () 
  { 
      ls *gz | xargs pkg_info -X | bzip2 > pkg_summary.bz2
  }

and, if you aren't keeping binary packages when you build from source,
change how you're doing that too :-)

> Basically, this was just to point out that probably something is not DTRT.
> Unfortunately, all other machines i currently have running uses python311 only, so no good way to replicate that on a cleaner system.

There may well be a bug.  Good luck finding that, or figuring out what's
wrong on your system, and letting us know or straightening it out.