On 24/03/2024 18:51, Brian Inglis via Cygwin-apps wrote:
On 2024-03-24 11:46, Jon Turney via Cygwin-apps wrote:
On 24/03/2024 17:31, Marco Atzeri via Cygwin-apps wrote:
On 24/03/2024 15:07, Jon Turney wrote:
On 24/09/2023 13:32, Jon Turney via Cygwin-apps wrote:
[...]
Not sure why my source package nghttp2 shows python install packages,
when they were dropped after 1.43 IIRC: build deps no longer include
python/-devel?
If you haven't taken any specific action to retire the python-3x-nghttp2
packages, the existing ones will continue to be available indefinitely.
Firstly, it seems there's a question here about what are upstream's
plans for the users of the python bindings for this library.
Are they supposed to migrate to some alternate bindings maybe available
from a separate repo? Or are they just out of luck?
And why does that nghttp2 source package show a dozen archived source
versions, when its installed packages have only three?
The simple answer to that is we retain the source package for all
available install packages. This seems essential for an open-source
project.
Now, as to why there are so many installable packages, this is the
intersection of a couple of unfortunate issues.
1. 'python3-nghttp2' is an "old-style" obsoletion package, where the
package exists, but is of category _obsolete, and requires the
replacement package.
These are terrible, because we can't remove the obsolete package because
that's what records the fact of obsoletion.
I actually have some code for calm to internally convert that to a
"new-style" obsoletion, where the replacement package itself records the
obsoletion (i.e. python36-nghttp2 obsoletes: python3-nghttp2), which it
continues to remember about even after the package which contains that
obsoleting is expired.
Once that's done, all those "old-style" obsoletion packages lingering in
our package repository can be removed (along with their corresponding
source).
But I still need to do some testing before that can be deployed.
(However, all that's probably not what's actually wanted with python
packages: it's preferable to have python3-foo be a virtual package which
pulls in python3x-foo, where python3x is the current python, so that
scripted installs can be written which ask for python3 and python3-foo
and continue to work while x changes...)
2. We haven't purged old python versions for a long time, so e.g the
python36 binding packages are still lingering.
As you can see, I'm just now getting around to looking at expiring
python36, which eventually should lead to python36-nghttp2 being expired
(insert some observations about how it doesn't have to be me doing these
things here)...
Feel free to purge as appropriate, or tell me what to add to cygport,
hints, etc!
So, the long list of source versions will hopefully be reduced in the
fullness of time...