From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from re-prd-fep-047.btinternet.com (mailomta10-re.btinternet.com [213.120.69.103]) by sourceware.org (Postfix) with ESMTPS id 317DB3858D20 for ; Thu, 17 Feb 2022 15:43:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 317DB3858D20 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=dronecode.org.uk Authentication-Results: sourceware.org; spf=none smtp.mailfrom=dronecode.org.uk Received: from re-prd-rgout-005.btmx-prd.synchronoss.net ([10.2.54.8]) by re-prd-fep-047.btinternet.com with ESMTP id <20220217154336.WLZV23513.re-prd-fep-047.btinternet.com@re-prd-rgout-005.btmx-prd.synchronoss.net> for ; Thu, 17 Feb 2022 15:43:36 +0000 Authentication-Results: btinternet.com; auth=pass (PLAIN) smtp.auth=jonturney@btinternet.com; bimi=skipped X-SNCR-Rigid: 613A912414FC1138 X-Originating-IP: [86.139.167.74] X-OWM-Source-IP: 86.139.167.74 (GB) X-OWM-Env-Sender: jonturney@btinternet.com X-VadeSecure-score: verdict=clean score=0/300, class=clean X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgedvvddrjeekgdejkecutefuodetggdotefrodftvfcurfhrohhfihhlvgemuceutffkvffkuffjvffgnffgvefqofdpqfgfvfenuceurghilhhouhhtmecufedtudenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepkfffgggfuffvfhfhjggtgfesthejredttdefjeenucfhrhhomheplfhonhcuvfhurhhnvgihuceojhhonhdrthhurhhnvgihsegurhhonhgvtghouggvrdhorhhgrdhukheqnecuggftrfgrthhtvghrnhepffekiefgudejheetudeigfejledtleegleetkeduteeftdfffefhueefgfeutedtnecukfhppeekiedrudefledrudeijedrjeegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehhvghloheplgduledvrdduieekrddurddutdefngdpihhnvghtpeekiedrudefledrudeijedrjeegpdhmrghilhhfrhhomhepjhhonhdrthhurhhnvgihsegurhhonhgvtghouggvrdhorhhgrdhukhdpnhgspghrtghpthhtohepuddprhgtphhtthhopegthihgfihinhestgihghifihhnrdgtohhm X-RazorGate-Vade-Verdict: clean 0 X-RazorGate-Vade-Classification: clean Received: from [192.168.1.103] (86.139.167.74) by re-prd-rgout-005.btmx-prd.synchronoss.net (5.8.716.04) (authenticated as jonturney@btinternet.com) id 613A912414FC1138 for cygwin@cygwin.com; Thu, 17 Feb 2022 15:43:36 +0000 Message-ID: Date: Thu, 17 Feb 2022 15:42:56 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.6.0 Subject: Re: Inconsistent handling of python3-module vs python3x-module packages Content-Language: en-GB To: The Cygwin Mailing List References: <20220216111059.ve7myugtwi7bjggb@lucy.dinwoodie.org> From: Jon Turney In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3570.8 required=5.0 tests=BAYES_00, FORGED_SPF_HELO, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_PASS, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: cygwin@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2022 15:43:43 -0000 On 16/02/2022 11:45, marco atzeri wrote: > On Wed, Feb 16, 2022 at 12:11 PM Adam Dinwoodie wrote: >> >> While wrangling a bunch of Python packages for my Cygwin installation, >> I've noticed an inconsistency about how python3 vs python3x packages are >> installed. > > Only one ? ;-) > >> As an example: the python3 package itself describes itself as a >> meta-package; the package itself is almost empty, and the key thing >> selecting the package does is depend on the latest python3x package, >> currently python39. The same behaviour is in place with, for example, >> python3-tkinter. > > Yes, these are real meta packages that pull the latest version > >> However the python3-pytest package is marked as obsolete, and is >> obsoleted by python36-pytest. If I select python3-pytest for >> installation, the package that's actually installed is python36-pytest, >> even though there's a python39-pytest package available. >> >> This inconsistency means that someone naively installing python3-tkinter >> and python3-pytest will end up with both python3.9 and python3.6 >> installed, with neither installation having access to both the pytest >> and tkinter modules. > > This is an artifact of of cygport creating python3-xxxx packages > also for packages that never had a real package called like that. > We had a discussion if it was worth to make the python3-xxxx pulling the > python39-xxxx instead of python39-xxxx and it was decided against it. I think this is more the emergent behaviour due to various changes than the result of a considered decision. >> I think this inconsistency is liable to cause confusion; it certainly >> confused me until I worked out what was going on. In my ideal world, >> we'd be in a situation where I could specify `python3-foo` to an install >> script and it'd automatically pick up the latest Python version >> available; I could specify `python3x-foo` if I wanted a specific older >> release. But at the very least, I'd really like to see these packages >> being handled consistently one way or another. > > I expect no one looking for a package will look for obsolete packages. It makes 'install python3-foo' a moving target for scripts. Patches to cygport to make this work better welcome!