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 0AD66138010 for ; Thu, 30 Aug 2012 23:59:48 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 0BD9DE0484; Thu, 30 Aug 2012 23:59:24 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 3070AE0369 for ; Thu, 30 Aug 2012 23:58:21 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 3CBC333D90B for ; Thu, 30 Aug 2012 23:58:20 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -1.569 X-Spam-Level: X-Spam-Status: No, score=-1.569 tagged_above=-999 required=5.5 tests=[AWL=-1.360, 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 g6tud2QOYI_2 for ; Thu, 30 Aug 2012 23:58:14 +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 E3CC433D906 for ; Thu, 30 Aug 2012 23:58:12 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1T7Eck-00067u-EG for gentoo-dev@gentoo.org; Fri, 31 Aug 2012 01:58:10 +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 01:58:10 +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 01:58:10 +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: Thu, 30 Aug 2012 23:58:00 +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: fe663c1a-43c6-48b7-be25-2bcc67265ef8 X-Archives-Hash: 29752a1d2fcae93d5388ac5fe8344790 Ciaran McCreesh posted on Thu, 30 Aug 2012 21:11:02 +0100 as excerpted: > On Thu, 30 Aug 2012 16:05:52 -0400 Michael Mol > wrote: >> Compile a list of existing ebuilds which depend on old EAPIs, and >> you've got a TODO list. (eclasses, I don't know; I don't know if >> eclasses explicitly express EAPI compatibility in metadata) Once that >> list is cleared, yes, you can assume there are no ebuilds with a >> specified EAPI of 0. I'd presume it would have been made widely known >> that new ebuilds shouldn't use the old EAPI by that point, and so >> support for the deprecated EAPI level can be abandoned. > > You can't uninstall a package if you don't support its EAPI. > > The "remove code" benefit applies to eclasses, not package manglers. I've seen that reason given before, and it makes sense... to a point. Would this work, tho? In addition to the tree clean of EAPI-X to be dropped... Some minimum time/versions (say six months) before a PM drops support for it, on PM upgrades it starts warning about the coming drop of EAPI-X support, giving the user a reasonable deadline (the same six months) to upgrade or uninstall said packages as PM versions after that date will be dropping support. Then at a shorter deadline (say two months), start warning at each PM invocation. When the upgrade that will drop support appears, if any packages of now unsupported EAPI-X remain installed, it simply dies with a warning that upgrading isn't possible as unsupported packages remain installed, instructing the user to upgrade or unmerge them first, before upgrading the PM. By this time, the tree would have been clean of EAPI-X for the longer deadline (six months in this example), and the warning will have appeared on PM upgrade for the same period and on every PM invocation for the shorter period (two months here), so people doing anything close to regular upgrades will have long since upgraded past or unmerged whatever lagging packages they had merged. For the people that do NOT upgrade frequently, the die before PM upgrade will force the issue, if/when they DO decide to upgrade. Covering the case where the troublesome packages themselves have moved on beyond something the installed PM can handle, it's still possible to unmerge the package temporarily, then merge it again after they upgrade. (If thought necessary, the usual I_KNOW_WHAT_IM_DOING override could be inserted, but in this case I think simply having them unmerge the packages in question is the safer alternative. After all, it's only going to hit the folks who are SO far out of date that there's no bridging package version available, for the offending package.) Of course there'd need to be special consideration given to critical toolchain and system boot packages, but /that's/ nothing new. And as has always been the case, for the /extreme/ laggards, at some point, say two years out or whatever, simply don't support upgrading that far any more, with a clean install from stage-3 being the recommended alternative. Of course an individual PM could choose to keep support for as long as they want, but unless I'm missing something, that'd let PMs drop support for old EAPIs if desired, with at least a reasonably sane upgrade path for both PM devs and users. -- 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