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 1LcHV4-00009G-Pd for garchives@archives.gentoo.org; Wed, 25 Feb 2009 11:00:27 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 7C76DE0456; Wed, 25 Feb 2009 11:00:25 +0000 (UTC) Received: from sauxb.salomon.at (smtp.salomon.at [193.186.16.13]) by pigeon.gentoo.org (Postfix) with ESMTP id 2AF84E0456 for ; Wed, 25 Feb 2009 11:00:25 +0000 (UTC) Received: from servex01.wamas.com (servex01.salomon.at [172.28.2.2]) by sauxb.salomon.at (8.12.10/8.12.10) with ESMTP id n1PAxKCe002171 for ; Wed, 25 Feb 2009 11:59:23 +0100 (MET) Received: from [172.28.8.78] ([172.28.8.78]) by servex01.wamas.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Feb 2009 11:59:19 +0100 Subject: Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives From: Michael Haubenwallner To: gentoo-dev@lists.gentoo.org In-Reply-To: <49A472E3.1010204@gentoo.org> References: <49A472E3.1010204@gentoo.org> Content-Type: text/plain; charset=ISO-8859-15 Date: Wed, 25 Feb 2009 11:59:19 +0100 Message-Id: <1235559559.20348.151.camel@sapc154.salomon.at> 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 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 25 Feb 2009 10:59:19.0977 (UTC) FILETIME=[1BF4F190:01C99738] X-Spam-Info: -0.73 () ALL_TRUSTED,BAYES_50,SPF_NEUTRAL X-Scanned-By: MIMEDefang 2.54 on 172.28.2.13 X-Archives-Salt: ec7d2e8a-0c02-44a2-89b9-7d7588dc35b8 X-Archives-Hash: 804720a3a98220da1d369bb02bca9342 On Wed, 2009-02-25 at 00:21 +0200, Petteri R=E4ty wrote: > get opinions [..] to get some idea what the general developer pool thinks= . > only allowed to post a single reply to this thread Thank you for that, I usually don't follow long threads, so apologies if things have been discussed already. Basically, I'm all for having GLEP55 "as good as possible" in favour of "as soon as possible" before implementation, even if it fits my thoughts quite good already (see below). > 2) EAPI in file extension IMO, this should define *how* to read the *final* EAPI from the ebuild. The *how* does not necessarily mean to /source/ the ebuild, so the terms "pre-source EAPI" and "post-source EAPI" IMHO are too strongly focussing on "(bash)> source $EBUILD" when used in a generic GLEP. Eventually, the "pre-source" EAPI could be called "major" EAPI, and the "post-source" EAPI could be called "major.minor" EAPI (see below). The "EAPI in file extension" also should define the filename-part of the versioning rules. > a) .ebuild- > c) .. > - ignored by current Portage > b) ..ebuild > - current Portage does not work with this "ignored by current portage" is an important point for me to *theorethically* guarantee for a possible upgrade path even over long time. > 3) EAPI in locked down place in the ebuild This "lock down" should be done by "EAPI in file extension" above. "lock down" can mean any of: "post-source (real bash-source)", "self-parse (grep?)", "fixed-byte/line-offset", "..." My thoughts are to split EAPI into several levels (rename them however you like): entry-point: Specifies how to read the "filename-scope" EAPI. filename-scope EAPI: Think as "major" EAPI. Specifies the filename-part of versioning rules. Specifies how to read the "global-scope" EAPI (can, but eventually should not require bash-sourcing the ebuild). May allow to not define "minor", assuming "$major.0.0" then. =20 global-scope EAPI: Think as "$major.minor" EAPI. May specify how to define additional versioning rules. Specifies how to define metadata information. Specifies which metadata information is required/optional/cached/... Specifies how to utilize external resources (eclasses). Specifies which/how actions can/must be defined (pkg_*, src_* functions). Specifies how to read the "local-scope" EAPI. May allow to not define "micro", assuming "$major.$minor.0" then. May disallow a "local-scope" EAPI, specifies it instead. =20 local-scope EAPI: Think as "$major.$minor.micro" EAPI. Specifies which PM-functions are available for use in actions (fex 'doman' inside src_install). May be specified as part of "minor" EAPI. Thanks! /haubi/ --=20 Michael Haubenwallner Gentoo on a different level