From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1M53gx-0001ZE-DY for garchives@archives.gentoo.org; Fri, 15 May 2009 20:07:39 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 0431DE04A1; Fri, 15 May 2009 20:07:38 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id B4577E04A1 for ; Fri, 15 May 2009 20:07:37 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 4325664BA4 for ; Fri, 15 May 2009 20:07:37 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: -0.872 X-Spam-Level: X-Spam-Status: No, score=-0.872 required=5.5 tests=[AWL=0.660, 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 CqcVtjW00vH8 for ; Fri, 15 May 2009 20:07:31 +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 0EE95652AF for ; Fri, 15 May 2009 20:07:29 +0000 (UTC) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1M53gl-0001Hs-VZ for gentoo-dev@gentoo.org; Fri, 15 May 2009 20:07:27 +0000 Received: from 82.152.214.146 ([82.152.214.146]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 15 May 2009 20:07:27 +0000 Received: from slong by 82.152.214.146 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 15 May 2009 20:07:27 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Steven J Long Subject: [gentoo-dev] Re: Re: The fallacies of GLEP55 Date: Fri, 15 May 2009 21:06:13 +0100 Organization: Friendly-Coders Message-ID: <1876706.o0cNKnX3bN@news.friendly-coders.info> References: <200905142006.51998.patrick@gentoo.org> <20090514193907.56754ae6@snowcone> <4A0D479F.7040107@gentoo.org> <3957741d4885eeb5a84ffcf262e58344@smtp.hushmail.com> <2682903.cnFe8369yH@news.friendly-coders.info> <20090515201757.4dd324dd@snowmobile> 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=us-ascii Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 82.152.214.146 Sender: news X-Archives-Salt: 42711155-aafd-4729-843b-6947b4a2353a X-Archives-Hash: ddc54e39227c77792c4b9b207049589d Ciaran McCreesh wrote: > Steven J Long wrote: >> Robert R. Russell wrote: >> >> > If I understand the problem GLEP 55 is trying to solve correctly, >> > it stems from portage's assumption that an unknown EAPI is equal to >> > EAPI 0. >> >> No, portage will reject an ebuild with an unknown EAPI, as per the >> spec. > > You're confusing the term 'unknown' here. > > Before an ebuild has had its metadata generated, its EAPI is unknown. At > this point, the package manager assumes EAPI 0. > With the format restriction, that everyone last year seemed happy with, apart from the few pushing GLEP-55, this isn't an issue. The mangler *should* be scanning first for the EAPI to see if it can even handle the rest of the ebuild (assuming it's not from the main tree or an upstream overlay, or we're not a normal user. Developer machines rightly need to do a bit more work, but it's not exactly onerous since portage automatically does it for you.) > After an ebuild has had its metadata generated, its EAPI is either > known or unsupported, but if known may be unspecified. If it is known > but unspecified, the package manager treats it as equivalent to EAPI 0. > Yes, empty = 0 as well-understood. > Conceptually, these aren't the same thing. > In practical terms, this is a useless proposal. It rightly got trashed last year. Let's just use a prefix instead of a suffix to indicate vcs, keep branch and upstream for dep specification, not filename, to allow inter-repo dependency for overlays for the few cases where it's actually needed, and add debian-style epochs to guarantee future expansion. If you have a use-case that actually requires more in a version specifier for upstream software, please present it and explain how it cannot be represented with the above. In passing, I must express bewildered amusement at the idea of a format with an unlimited amount of extensions. If you really want something so radically different that it cannot be handled in the Gentoo scheme, or BASH, use ONE _other_ extension. Have a good weekend, all. -- #friendly-coders -- We're friendly but we're not /that/ friendly ;-)