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 C35E0138010 for ; Fri, 31 Aug 2012 03:35:34 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id AF1ABE059B; Fri, 31 Aug 2012 03:35:06 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 479E6E01C5 for ; Fri, 31 Aug 2012 03:33:47 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 7DF7233D853 for ; Fri, 31 Aug 2012 03:33:46 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5.5 tests=[AWL=-1.358, RP_MATCHES_RCVD=-0.207, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EP_Lpxa4PGzS for ; Fri, 31 Aug 2012 03:33:40 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id 8E1DE33D7C7 for ; Fri, 31 Aug 2012 03:33:40 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1T7HzD-0002Mf-4x for gentoo-dev@gentoo.org; Fri, 31 Aug 2012 05:33:35 +0200 Received: from ip68-231-22-224.ph.ph.cox.net ([68.231.22.224]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 31 Aug 2012 05:33:35 +0200 Received: from 1i5t5.duncan by ip68-231-22-224.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 31 Aug 2012 05:33:35 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: EAPI usage Date: Fri, 31 Aug 2012 03:33:25 +0000 (UTC) Message-ID: References: <1650487.RNHkTcOSMI@elia> <1941775.YCGWEdgpfQ@elia> <503F64D1.6000203@gentoo.org> <503FC35A.1030407@gentoo.org> <20120830211102.177f7fcf@googlemail.com> 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 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-22-224.ph.ph.cox.net User-Agent: Pan/0.139 (Sexual Chocolate; GIT 1f91845 /usr/src/portage/src/egit-src/pan2) X-Archives-Salt: b04f3c47-336e-485c-8676-14e3b2bf1498 X-Archives-Hash: cec2175bab4a9058c2c6f55cfcaaa8f3 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. Meanwhile, I'll definitely allow that there's often a big chasm between "possible" and "worth the trouble", too, and it's quite within the realm of reason that it's simply "not worth the trouble" at this point, even if very much possible, and even likely worth the trouble once we get upto say 10 EAPIs or some such. Meanwhile(2), I (cautiously) support the idea I've seen before of deprecating and gradually removing at least EAPI-1, and probably 2 and 3 as well over time. People /have/ pointed out that core system packages, toolchain, etc, may well need to stay at EAPI-0 virtually "forever". That's the exception I mentioned with EAPI-0 thus being an exception as well, thus the focus on 1-3. But once 1-3 are out of the tree for a sufficient period, I really /don't/ see why the method I described can't be used to drop their support from the PMs, as well, and expect that regardless of whether it's worth tackling as a project starting today, at some point, it'll be worth doing. OTOH, I can see someone, possibly concerned about the historical implications (so "gentoo historians" at least, can try long deprecated ebuilds and see how they work), might wish to maintain support for every EAPI "forever". But I don't believe it should be mandatory, and in practice, I'd venture that due to simple code rot once there haven't been any packages of a particular EAPI in the tree or in wide circulation for awhile, even if support /does/ officially continue, it'll likely be broken if anyone tries to use it, say five years or a decade later. Once that starts being a major concern, why /not/ just dump it. The historians can go find an old stage tarball with an old PM that supported the EAPIs they're interested in, if it comes to that. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman