Re: Documented way to update python?

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

> Date: Fri, 27 Oct 2023 15:48:02 -0400
> From: 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.

Does it have to conflict?  The full package, say py311-sqlite3, still
lives under $PREFIX/lib/python3.11, and the new Python sqlite3 lives
under $PREFIX/lib/python3.12, right?  So it's a question of whether
the _stub_ package needs to conflict with the full package.

But, whatever the mechanism is, I think we should treat it as a high
priority for `pkgin update && pkgin upgrade' to do the right thing for
anyone following a binary package repository.  Any requirement for
manual intervention should be treated as a severe bug in whatever it
is we're doing.

Similar deal for pkg_rolling-replace, although that priority can be
lower because the expectation for tracking source is that you are a
developer who can diagnose hiccups.