Re: Documented way to update python?

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

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

>> 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.

The change that just happened is that the old way installed a set of
files with (without loss of generality, describing only one split package)

  python-3.11
  py311-sqlite3

and the new way installs the union of those files in

  python-3.11

You are bringing up 3.11 vs 3.12, and perhaps saying "but instead of
doing what we did, we could have made python3.11 stay the same and only
done this for 3.12".  But that's not what happened, and I prefer
consistency to avoiding this hiccup.

> 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.

I am pretty sure any quality patches that arise will get attention...

This is not a new problem.  Things like this have been happening for
years, with the foo package splitting into foo-libs and foo, where foo
depends on foo-libs.  It's been happening with tex, more years ago than
now, when files just get moved.

The basic issue is to be able to express "remove these N and add those M
and here's the dependency map" and then have a way to do it.  That's a
fair bit of work and so far nobody has been motivated to do it.

> 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.

For the most part, the issues are in "make replace" rather than
"pkg_rolling replace", but sure.  Again, we'll see what patches arise.