Re: Documented way to update python?

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

Taylor R Campbell <campbell+netbsd-tech-pkg%mumble.net@localhost> writes:

>> > Is it just a pkg_delete -f py-curses, py-expat, py-readline and py-sqlite3,
>> > then pkg_rolling-replace?
>> 
>> That will probably work. But also remove py-cursespanel and
>> py-cElementTree, if installed.
>
> This strikes me as a bad user experience -- why do we need any manual
> intervention for an upgrade to work?  Can we have stub py312-expat &c.
> packages that don't do anything?

The problem is that new python conflicts with old py-foo, for foo that
is no longer bundleed.

To address this requires:

  declarative statements that
    python-3.11.6nb3 both conflicts with, and makes unnecessary
    py311-sqlite3

  support in "make replace", perhaps, and pkgin, to have an atomic
  operation of ugprading python and removing others and backpatching the
  things that depend on python and py-sqlite3 to only depend on python

Having an empty py-sqlite3 only helps a little, and doesn't fix the
conflict, which is the hard part.

> There's also the broader issue of -- if I want pyN-mumblefrotz
> installed where N is the current default Python version, and I want to
> update packages after the default is now N+1, how can I get the system
> to automagically update to py(N+1)-mumblefrotz?

You can't, really, because you deciding you want to move py-foo  from N
to N+1 is separate from where it needs to be.  There are two steps:

  1) For each package that has a python-version and that is not marked
  automatic, build the new one and set automatic on the old one.

  2) teach pkg_chk/pkg_rr to output pairs of pkgname/pkgpath plus
  variable settings, so we can make replace in py310-foo and py311-foo
  independently.

  3) For each py-foo where pyN-foo and pyN+1-foo conflict, because on
  non-namespaced filenames, set the wayback machine and fix that.


After that's done, the combination of
  execute step 1
  pkg_rr
  pkgin ar
should mostly work.