From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.13]) by sourceware.org (Postfix) with ESMTPS id 2C902386F803 for ; Mon, 18 Jan 2021 20:58:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 2C902386F803 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=SystematicSw.ab.ca Authentication-Results: sourceware.org; spf=none smtp.mailfrom=brian.inglis@systematicsw.ab.ca Received: from [192.168.1.104] ([24.64.172.44]) by shaw.ca with ESMTP id 1bb9l9A0stdld1bbAlCcp6; Mon, 18 Jan 2021 13:58:05 -0700 X-Authority-Analysis: v=2.4 cv=INe8tijG c=1 sm=1 tr=0 ts=6005f65d a=kiZT5GMN3KAWqtYcXc+/4Q==:117 a=kiZT5GMN3KAWqtYcXc+/4Q==:17 a=IkcTkHD0fZMA:10 a=ejknC5xS72zp2OFXFO8A:9 a=QEXdDO2ut3YA:10 Reply-To: cygwin-apps@cygwin.com To: cygwin-apps@cygwin.com References: <4e2b7b2f-0a94-0723-77a2-f9fddf905a6d@SystematicSw.ab.ca> <5ea5278e-1d68-34cd-9e53-8a6222cac94f@gmail.com> From: Brian Inglis Organization: Systematic Software Subject: Re: python 2 check & cleaning Message-ID: <247e8e25-dce1-bf15-c7e2-ab345d6b43f6@SystematicSw.ab.ca> Date: Mon, 18 Jan 2021 13:58:03 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: <5ea5278e-1d68-34cd-9e53-8a6222cac94f@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-CA Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4xfAz58tP4JUESESjAVRBfF7Y1+Vi2bxTfzHICYq3ka47TaYvcDlgvI5fdaf9DZImUlQB8z9MWcuxwlVbCxvtBQCyksmOo3d8mpZ9C8EnA9vtRIKfsO3Ll 3Nn1XRIUABkG+A1vl/Wy09oIx2NVV2xAVScI6Kfum4ns+xhm/HN2JP5mB8ZRGkNgwYhWVzWqbgjJ6Q+30N/AdaEeada6o9zaP+8= X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: cygwin-apps@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Cygwin package maintainer discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2021 20:58:08 -0000 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.]