From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1Kq49r-0001sB-6a for garchives@archives.gentoo.org; Wed, 15 Oct 2008 11:03:16 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 40AFCE01C2; Wed, 15 Oct 2008 11:03:12 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id EEC99E01C2 for ; Wed, 15 Oct 2008 11:03:11 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id D57F564541 for ; Wed, 15 Oct 2008 11:03:09 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 required=5.5 tests=[AWL=0.897, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_NUMERIC_HELO=2.067] 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 4KU4QKwvf7ji for ; Wed, 15 Oct 2008 11:03:03 +0000 (UTC) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id 33D4064B7A for ; Wed, 15 Oct 2008 11:03:02 +0000 (UTC) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Kq49W-0002bB-GM for gentoo-dev@gentoo.org; Wed, 15 Oct 2008 11:02:54 +0000 Received: from 82.153.199.203 ([82.153.199.203]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 15 Oct 2008 11:02:54 +0000 Received: from slong by 82.153.199.203 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 15 Oct 2008 11:02:54 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Steve Long Subject: [gentoo-dev] Re: Stabilize ebuilds which use EAPIs only supported by ~arch PMs Date: Wed, 15 Oct 2008 11:50:57 +0100 Message-ID: References: <20081014000340.GA5494@gentoo.org> <20081014003834.GE23706@comet> <20081014085939.GA5520@gentoo.org> <20081014181712.1a5ad3c7@sheridan.genone.homeip.net> <48F51E8B.9000600@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 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 82.153.199.203 User-Agent: KNode/0.10.9 Sender: news Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 7f09012a-2e5a-484b-9cbb-841eb14d825a X-Archives-Hash: b710c7b42143e6b1691b520d690f6a7e Alec Warner wrote: > Petteri R=E4ty wrote: >> There's no need to commit straight to stable. Just make two different >> new revisions for each EAPI. Then the arch teams can test it like usua= l. >=20 > Aha a perfect canidate use case for GLEP 55[1] that fends off 'why are > there multiple versions of the same package' questions and > complexities. > Hmm AFAICT there isn't any need to do put it in the filename, as the pack= age manager will simply ignore an EAPI (which comes from the rsync'ed cache f= or the Gentoo tree) it doesn't know. Additionally all the manglers deal with EAPI 0-2 fine afaik. If it's solely about the different rev ids, I think it's a bit of a red herring; anyone confused could simply be told "this i= s a security fix" if they cared to ask (or look in the Changelog) and these aren't exactly going to be all over the tree. Could be masked "for arch-testing [security fix]" and then the relevant fixed older version pu= t into the tree, as now. Personally I'd rather remove the restriction and allow ebuilds to work wi= th more than one EAPI, as explicitly declared, instead of having to write tw= o revisions. One could then also inherit from a security eclass to make it clear to anyone reading the ebuild what was happening (which would also work for two different revs with variant EAPIs ofc.) Whatever, I don't think this use-case is anywhere near enough to justify = the massive intrusion that GLEP55 is. The versioning thing brought up before = is best done via debian-style epochs, if anyone really wants to fix that.