From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 66A58138010 for ; Fri, 31 Aug 2012 14:25:00 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E368BE0587; Fri, 31 Aug 2012 14:24:39 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id E92B5E04CB for ; Fri, 31 Aug 2012 14:23:45 +0000 (UTC) Received: from [192.168.26.5] (ip98-164-193-252.oc.oc.cox.net [98.164.193.252]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: zmedico) by smtp.gentoo.org (Postfix) with ESMTPSA id 6E54B33D718 for ; Fri, 31 Aug 2012 14:23:45 +0000 (UTC) Message-ID: <5040C8EF.6000609@gentoo.org> Date: Fri, 31 Aug 2012 07:23:43 -0700 From: Zac Medico User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:14.0) Gecko/20120802 Thunderbird/14.0 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 MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: EAPI usage References: <1650487.RNHkTcOSMI@elia> <1941775.YCGWEdgpfQ@elia> <503F64D1.6000203@gentoo.org> <503FC35A.1030407@gentoo.org> <20120830211102.177f7fcf@googlemail.com> In-Reply-To: X-Enigmail-Version: 1.5a1pre Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Archives-Salt: 33518ebc-ff5e-4212-aa7e-4260a59b46c7 X-Archives-Hash: 70abd728a1b94b84154836c76f008e7f On 08/30/2012 08:33 PM, Duncan wrote: > Rich Freeman posted on Thu, 30 Aug 2012 20:38:11 -0400 as excerpted: > >> My main concern is doing bumps all the time just for their own sake. > > Yes. That's why I didn't tackle that side at all. But I've seen the > "PM's can never drop support for an EAPI once adopted" thing before, and > while there's quite a possibility I'm missing something as I'm no PM > expert, it does seem to me that rings hollow; that an EAPI drop COULD be > done, without too much disrupting either users or devs (PM or otherwise). > > But as the experts say otherwise, there probably /is/ something I'm > missing, which is why I asked. It would be a bad idea to remove support for *uninstalling* an ebuild with a given EAPI, since any given system that the PM encounters could potentially have ebuilds with any old EAPI installed. OTOH, removing support for *installing* a given EAPI is quite feasible. In Portage, we occasionally deprecate EAPIs that only existed for the purpose of testing. Once an EAPI is deprecated, ebuilds using that EAPI can no longer be installed, but they can still be uninstalled (including execution of pkg_prerm/pkg_postrm phases). That said, deprecation of official EAPIs such as EAPI 0, 1, and 2 would not lead to much code being removed, because the later EAPIs share so much code with them. So, deprecating official EAPIs provides little or no benefit in terms of code maintenance. -- Thanks, Zac