From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 0D9D3138359 for ; Fri, 4 Sep 2020 12:54:24 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C0B0BE085E; Fri, 4 Sep 2020 12:54:20 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 806DDE07FE for ; Fri, 4 Sep 2020 12:54:20 +0000 (UTC) Date: Fri, 4 Sep 2020 14:54:13 +0200 From: Alexis Ballier To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Please port your packages to Python 3.8 Message-ID: <20200904145413.0331c104@pepito> In-Reply-To: References: <6bce27ad-fb72-011a-e10d-ab4c44c845ae@gentoo.org> <4384119.vXUDI8C0e8@tuxbrain> <20200903183807.58564cc2@pepito> Organization: Gentoo X-Mailer: Claws Mail 3.17.6 (GTK+ 2.24.32; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Archives-Salt: 7f6bd711-2633-4ba8-a5f3-ca73e6d13f04 X-Archives-Hash: 1d4c5e88cf19b1c248aea2023d686dc5 On Thu, 3 Sep 2020 14:17:06 -0400 Michael Orlitzky wrote: > On 2020-09-03 12:38, Alexis Ballier wrote: > > > > if some upgrade wants a package with unmatched deps (e.g. not > > installed at all or py38 usedep not satisfied), $PM will surely try > > to satisfy it by installing an ebuild. I don't think PMS specifies > > this, nor should it. > > > > It's not an upgrade per se. The situation is roughly this: > > 1. User installs foo-1.2.3.ebuild, which supports python-3.7. > 2. Developer ninja-edits the ebuild to support python-3.8. > 3a. (crickets) > 4a. Developer removes python-3.7 support from foo-1.2.3.ebuild. > 5a. The next time something pulls foo-1.2.3 into the depgraph, > the PM will see that the installed version of foo-1.2.3 depends > on python-3.7, but that there is no python-3.7 in the tree or that > it's masked. Now emerge always fails. py37 will (*) still be installed as it cannot be depcleaned because of 1. emerge won't fail since deps are satisfied. (*) or rather should, but I think the only case that matters is a valid system state where noone forced uninstall of a needed package or manually rm'ed some random files > > or.. > > 3b. Some reverse dependency of foo-1.2.3 gets python-3.8 support. > 4b. A user tries to install that revdep, but the PM sees that > the latest version of foo is already installed, and it (the > installed version) doesn't support python-3.8. Mysterious > error messages and manual intervention ensue. precisely the case I wrote above: unsatisfied dep -> pull ebuild. non-issue too. > What's happening is that the PM is using the metadata from the > installed version of the package, rather than the ninja-edited > metadata in the repo (how would it know which ebuilds were edited > meaningfully?). That's completely legal according to the PMS, and > also the smart thing to do: sourcing a few thousand lines of bash > *just in case* there was an important change in some ebuild is a huge > waste of users' time. you seem to be confusing dynamic deps and unsatisfied deps here. A package installed with py38 disabled (e.g. after a revbump) or no py38 support at all (e.g. without revbump) will not satisfy a [py38] usedep in any case so will work just the same > Developers have an easy way to signal that there was an important > change: to bump the "r" number at the end of the ebuild. This forces > any upgrade involving e.g. foo-1.2.3 to pull in foo-1.2.3-r1, and the > fact that an upgrade is available is evident from `ls`, rather than > from sourcing a mountain of bash. One developer makes a change, and > it saves thousands of users each a lot of time. That's what we're all > here for. fixing non-issues does not seem so important to me :/ [...]