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.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 7735B1581FB for ; Tue, 27 Aug 2024 21:36:58 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 663EAE2A58; Tue, 27 Aug 2024 21:36:54 +0000 (UTC) Received: from smtp.gentoo.org (woodpecker.gentoo.org [140.211.166.183]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 1A135E2A48 for ; Tue, 27 Aug 2024 21:36:54 +0000 (UTC) From: Sam James To: Eli Schwartz Cc: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [PATCH 00/50] XXXXXX.eclass: drop support for EAPI6 In-Reply-To: (Eli Schwartz's message of "Tue, 27 Aug 2024 17:16:03 -0400") Organization: Gentoo References: <20240827151553.210835-1-soap@gentoo.org> Date: Tue, 27 Aug 2024 22:36:49 +0100 Message-ID: <87r0a9bqby.fsf@gentoo.org> 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 X-Archives-Salt: 03f9af11-d0dd-467c-b5b8-f5a10fd5ec8f X-Archives-Hash: df865a3fc6db2edcbf8c53811d03a668 Eli Schwartz writes: > On 8/27/24 5:03 PM, Robin H. Johnson wrote: >> There wasn't an introduction message to this series, but I wanted to >> raise the discussion. >> >> We only JUST got rid of the last EAPI6 ebuilds in the main tree. >> >> There are overlays that still have EAPI6 ebuilds - and depend on these >> ebuilds. >> >> When is an expected time for all of those ebuilds to migrate, and how is >> that being communicated? > > > If we were removing an eclass that only supports EAPI 6 and is being > dropped because it's useless, we'd last rite it and give people 30 days > to move. > > But because the *file* isn't being removed, there is no rule how to do > it apparently?? :D The obvious answer here is to stick an ewarn in the > "if EAPI 6" branch at global scope. > > > (It's a bit messy when doing dependency calculation. This too is a > feature, if you think about it.) Yes, it's something which has bothered me for a while. When we ratified GLEP 83 [0], I wanted to come back to it for handling EAPI support deprecation in "important" eclasses but I couldn't figure out a nice definition for that and got distracted. I actually *do* think we should do something here, but I will note pkgcheck will have been warning about use of DeprecatedEapi at least. [0] https://www.gentoo.org/glep/glep-0083.html