From: Brian Inglis <Brian.Inglis@SystematicSw.ab.ca>
To: cygwin-apps@cygwin.com
Subject: Re: python 2 check & cleaning
Date: Mon, 18 Jan 2021 13:58:03 -0700 [thread overview]
Message-ID: <247e8e25-dce1-bf15-c7e2-ab345d6b43f6@SystematicSw.ab.ca> (raw)
In-Reply-To: <5ea5278e-1d68-34cd-9e53-8a6222cac94f@gmail.com>
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.]
next prev parent reply other threads:[~2021-01-18 20:58 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-18 5:33 Marco Atzeri
2021-01-18 7:21 ` Brian Inglis
2021-01-18 11:16 ` Marco Atzeri
2021-01-18 20:58 ` Brian Inglis [this message]
2021-01-18 18:25 ` Ken Brown
2021-01-19 15:10 ` Ken Brown
2021-01-19 15:39 ` Marco Atzeri
2021-01-18 22:28 ` Lemures Lemniscati
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=247e8e25-dce1-bf15-c7e2-ab345d6b43f6@SystematicSw.ab.ca \
--to=brian.inglis@systematicsw.ab.ca \
--cc=cygwin-apps@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).