On 2024-03-27 14:07, Jon Turney via Cygwin-apps wrote:
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?
SOL! Dropped them in 1.52, probably why 1.31.0..1.51.0 are hanging around.
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...
Could I just add to nghttp2.cygport that nghttp2 obsoletes
python{2{,7},3{,6,7,8,9}}-nghttp2?
Does this have to remain in the cygport forever to avoid keeping nghttp2 vx.x.x
around?
--
Take care. Thanks, Brian Inglis Calgary, Alberta, Canada
La perfection est atteinte Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry
