Re: [ITA] nghttp2, mingw64-{x86_64,i686}-nghttp2

[Brian Inglis <Brian.Inglis@SystematicSw.ab.ca>]

On 2021-05-29 00:12, Marco Atzeri via Cygwin-apps wrote:
> On 29.05.2021 06:37, Brian Inglis wrote:
>> On 2021-05-28 17:18, Brian Inglis wrote:
>>> On 2021-05-28 12:33, Marco Atzeri via Cygwin-apps wrote:
>>>> On 28.05.2021 19:06, Brian Inglis wrote:
>>>>> Noticing some more libraries used by curl and wget/2 that were outdated
>>>>> and orphaned, I decided to take a look at building updates and would now
>>>>> like to adopt them.
>>>>> The list below shows the distributed packages, links to the Git Cygwin
>>>>> Package repos (see playground branches), Appveyor CI builds and logs
>>>>> for those who prefer looking at those, and links to Google drive folders
>>>>> with all the usual files and archives for others.
>>>>> I have issues building python2/27/3/36 modules, and/or which to obsolete.

>>>> you can drop all.
>>>> Python2.7 is dead upstream and Python3.6 will be at end of 2021
>>>> https://www.python.org/downloads/

>>> I would appreciate advice on how to structure obsoleting the existing packages:
>>> python-nghttp2
>>> python2-nghttp2
>>> python27-nghttp2
>>> python3-nghttp2
>>> python36-nghttp2
>>> given replacement packages python37-nghttp2 and python38-nghttp2.
>>> I can define all those as empty packages for the proposed release,
>>> but which should obsolete what to get the appropriate replacements?
>>> Should I define the following packages e.g.:
>>>  python2-nghttp2 dummy obsoletes   python-nghttp2
>>> python27-nghttp2 dummy obsoletes  python2-nghttp2
>>>  python3-nghttp2 dummy obsoletes python27-nghttp2

> this make no sense

>>> python36-nghttp2 dummy obsoletes  python3-nghttp2
>>> python37-nghttp2 real  obsoletes python36-nghttp2

> usually I don´t do one full version to obsolete another full version

They are empty dummy packages to replace and upgrade the previous
packages to proposed rather than just orphaning them:

 >>> python2-nghttp2-1.43.0-1.tar.xz
*** Info: Creating empty package

 >>> python27-nghttp2-1.43.0-1.tar.xz
*** Info: Creating empty package

 >>> python3-nghttp2-1.43.0-1.tar.xz
*** Info: Creating empty package

 >>> python36-nghttp2-1.43.0-1.tar.xz
*** Info: Creating empty package

from cygport:

python2_nghttp2_CATEGORY="$CATEGORY Python"
python2_nghttp2_SUMMARY="$SUMMARY (Python 2)"
python2_nghttp2_OBSOLETES="python-nghttp2"
#python2_nghttp2_CONTENTS="usr/lib/python2/site-packages/*nghttp2*"

python27_nghttp2_CATEGORY="$CATEGORY Python"
python27_nghttp2_SUMMARY="$SUMMARY (Python 2.7)"
python27_nghttp2_OBSOLETES="python2-nghttp2"
#python27_nghttp2_CONTENTS="usr/lib/python2.7/site-packages/*nghttp2*"

python3_nghttp2_CATEGORY="$CATEGORY Python"
python3_nghttp2_SUMMARY="$SUMMARY (Python 3)"
python3_nghttp2_OBSOLETES="python27-nghttp2"
#python3_nghttp2_CONTENTS="usr/lib/python3/site-packages/*nghttp2*"

python36_nghttp2_CATEGORY="$CATEGORY Python"
python36_nghttp2_SUMMARY="$SUMMARY (Python 3.6)"
python36_nghttp2_OBSOLETES="python3-nghttp2"
#python36_nghttp2_CONTENTS="usr/lib/python3.6/site-packages/*nghttp2*"

python37_nghttp2_CATEGORY="$CATEGORY Python"
python37_nghttp2_SUMMARY="$SUMMARY (Python 3.7)"
python37_nghttp2_OBSOLETES="python36-nghttp2"
python37_nghttp2_CONTENTS="usr/lib/python3.7/site-packages/*nghttp2*"

python38_nghttp2_CATEGORY="$CATEGORY Python"
python38_nghttp2_SUMMARY="$SUMMARY (Python 3.8)"
python38_nghttp2_CONTENTS="usr/lib/python3.8/site-packages/*nghttp2*"

>>> python38-nghttp2 real  stands alone for now?

> I guess you can just avoid to pack
>    python2-nghttp2
>    python27-nghttp2
>    python36-nghttp2
> and obsoletes
>    python3-nghttp2
>    python-nghttp2
> from python38-nghttp2
> On ipython I packaged only 37 and 38, and calm did not complained of missing the other versions.

As package versions may be dependent in most cases but independent when products
support installing parallel versions, calm is DTRT.
But wouldn't not packaging upgrades just orphan the older packages, requiring
manual removal/addition, as when there is a version epoch break?
[I have no clue how python modules of different versions interact.]

>> I have changed the cygport to do the above and the results are here:
>> https://drive.google.com/drive/folders/1Ee4KNQ6EaTnh8MkqbLNxnEpBaw3JOaFk
>> until I can get git-cygwin-packages working again - see below!

>>>> Changed maintainership to you

>> Do I also have ownership of:
>> ssh://cygwin@cygwin.com/git/cygwin-packages/{,mingw64-{x86_64,i686}-}nghttp2.git? 

> should be
> but Jon is the expert here

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]