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