python 2 check & cleaning

[Brian Inglis]

On 2021-01-18 04:16, Marco Atzeri via Cygwin-apps wrote:
> On 18.01.2021 08:21, Brian Inglis wrote:
>> On 2021-01-17 22:33, Marco Atzeri via Cygwin-apps wrote:
>>> Could you please check your packages if they will work with
>>> preferred python3.8?
>>
>> @ units
>> ...
>> requires: cygwin findutils libreadline7 python3 python36 python36-requests
>> ...
>> depends2: cygwin, findutils, libreadline7, python36, python36-requests
>> build-depends: autoconf, binutils, coreutils, cygport, cygwin-devel, gawk, 
>> gcc-core, grep, libncurses-devel, libreadline-devel, perl_base, python3, 
>> python3-devel, python3-requests, sed, texinfo
>>
>> $ head -1 `which units_cur`
>> #!/usr/bin/python3.6m
>>
>> How can I ensure units depends2 and requires, and the script hash-bang uses 
>> only the generic python3, python3-devel, python3-requests like build-depends, 
>> and avoids using the "current" specific version 36/3.6m?

> python3-requests for the time being will pull python36-requests.
> 
> That is fine for your
>    #!/usr/bin/python3.6m
> 
> Cygport has hard coded the OBSOLETES, this is something
> we need to change in cygport:
> 
>  >>> python36-requests OBSOLETES: python3-requests

>> And how can I ensure that units_cur is tested using only python38 modules?
>> Will the hash-bang override the command line run python38 `which units_cur`?

> rebuilding from your source I had
> 
> units requires: cygwin findutils libreadline7 python38 python38-requests
> 
> It seems the "inherit python3" is pulling the current choice
> of my system
> 
> $ alternatives --display python3
> python3 - status is auto.
>   link currently points to /usr/bin/python3.8
> /usr/bin/python3.7 - priority 37
> /usr/bin/python3.6 - priority 36
> /usr/bin/python3.8 - priority 38
> Current `best' version is /usr/bin/python3.8.

Same on mine as of package release time.

I still have direct symlinks from installs:

$ llrt -go /bin/python{,[23]*}
-rwxr-xr-x  1 9.1K Apr 10  2020 /bin/python3.7m.exe*
lrwxrwxrwx  1   14 Apr 11  2020 /bin/python3.7 -> python3.7m.exe*
-rwxr-xr-x  1 9.1K May 23  2020 /bin/python2.7.exe*
-rwxr-xr-x  1 3.4K May 23  2020 /bin/python3.8-config*
-rwxr-xr-x+ 1 9.1K May 23  2020 /bin/python3.8.exe*
-rwxr-xr-x  1 3.4K Jun  8  2020 /bin/python3.6m-config*
-rwxr-xr-x  1 9.6K Jun  8  2020 /bin/python3.6m.exe*
lrwxrwxrwx  1   14 Jun 26  2020 /bin/python3.6 -> python3.6m.exe*
lrwxrwxrwx  1   13 Jun 26  2020 /bin/python -> python2.7.exe*
lrwxrwxrwx  1   13 Jun 26  2020 /bin/python2 -> python2.7.exe*
lrwxrwxrwx  1   17 Jun 26  2020 /bin/python3.6-config -> python3.6m-config*
lrwxrwxrwx  1   13 Jan  2 13:36 /bin/python3 -> python3.8.exe*
lrwxrwxrwx  1   16 Jan  2 13:39 /bin/python3-config -> python3.8-config*

Problem is if units goes quiet for a while, as it has sometimes for 2-3 years, 
averaging a release a year, it may require python3.X packages to stay around 
long after really required, even if obsoleted by many later releases, when it 
really just needs to depend on python3{,-requests}.
At the moment, python 3.6 has to stay around until the next units release!

I would rather not have to generate package releases per python release (or few) 
just for this, but I don't mind testing each.

Should I hack the build files next release to avoid resolving the symlinks and 
retain the base version?

[Units Version Release Dates

Version	  Released	Days
1.53    1997-01-14      183
1.54    1997-09-10      239
1.55    1999-07-30      688
1.74    2001-06-13      684
1.80    2002-06-17      369
1.85    2005-05-20     1068
1.86    2006-11-11      540
1.87    2007-09-26      319
1.88    2010-02-15      873
2.00    2012-06-28      864
2.01    2012-10-24      118
2.02    2013-07-11      260
2.10    2014-03-26      258
2.11    2014-04-02        7
2.12    2015-10-14      560
2.13    2016-06-21      251
2.14    2017-03-08      260
2.15    2017-10-23      229
2.16    2017-10-31        8
2.17    2018-06-25      237
2.18    2018-10-20      117
2.19    2019-05-31      223
2.20    2020-09-30      488
2.21    2020-11-15       46

    min 7  avg 370  max 1068]
-- 
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.]