From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.43) id 1E8Jlz-0001GO-CW for garchives@archives.gentoo.org; Thu, 25 Aug 2005 15:36:11 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.4/8.13.4) with SMTP id j7PFWtq2003620; Thu, 25 Aug 2005 15:32:55 GMT Received: from callisto.cs.kun.nl (callisto.cs.kun.nl [131.174.33.75]) by robin.gentoo.org (8.13.4/8.13.4) with ESMTP id j7PFRAP5024355 for ; Thu, 25 Aug 2005 15:27:11 GMT Received: from localhost (localhost [127.0.0.1]) by callisto.cs.kun.nl (Postfix) with ESMTP id 3026E2E8233 for ; Thu, 25 Aug 2005 12:34:02 +0200 (CEST) From: Paul de Vrieze To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] EBUILD_FORMAT support Date: Thu, 25 Aug 2005 12:34:00 +0200 User-Agent: KMail/1.8.2 References: <20050707002002.GH20687@lightning.stealer.net> <200508231520.16966.pauldv@gentoo.org> <20050823160045.GJ10816@nightcrawler> In-Reply-To: <20050823160045.GJ10816@nightcrawler> X-Face: #Lb+'V@sGJ;ptgo5}V"W+5OCoo{LZv;bh,s,`WKLi/J)ed1_$0;6X<=?utf-8?q?700LVV/=3BLqPhiDP=5E=0A=09=27f=5Dfnv?=@%6M8\'HR1t=aFx;ePfp{ZQoBe+e)JOQ8T5*(_;mHY+cltLGq<;@$Y,=?utf-8?q?O=5C=24=0A=09Tm=23G6M?=,g![Q62J{na*S9d;R[^8pc%u\aiLqU@`kJtYl"^6pxdW Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart12513654.VdYEYWWfmb"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200508251234.00876.pauldv@gentoo.org> X-Archives-Salt: 172b8483-fe6b-4b0f-ba5b-6ed2ecab323f X-Archives-Hash: e961aa1312135d74dd3d95efba79ed21 --nextPart12513654.VdYEYWWfmb Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 23 August 2005 18:00, Brian Harring wrote: > On Tue, Aug 23, 2005 at 03:20:16PM +0200, Paul de Vrieze wrote: > > To allow for this to work with current portage versions, perhaps it > > would be an option to introduce a new extension for .ebuild scripts > > that use it's functionality. That would allow all non-EAPI aware > > portage versions to automatically ignore ebuilds that use this. > > not much for .ebuild? in the tree, personally. > Why? Cause portage *should not* ignore those ebuilds. If the user > wants to merge something that is a later ebuild api then they have, at > least portage chucks an exception that the UI can wrap into "upgrade > portage". > > With what you're proposing, we instead get bugs about portage missing > packages. What I mean is compatibility with current portage versions. Current=20 versions do not understand EAPI. There would be a good chance that they=20 could choke on packages with all kinds of new features, even in the sync=20 phase. A different extension would ensure that those portage versions=20 would still work (crippled) on a new tree. Of course such an extension=20 change should only be done once. Once the API versions are available this=20 is not an issue. > > > ps. I would also suggest requiring that EAPI can be retrieved by a > > simple line by line parsing without using bash. (This allows for > > changing the parsing system) > > No, that's yanks EAPI setting away from eclasses. If the eclasses follow similar rules that would be easilly parseable.=20 (taking inherit ...) into account is easy as long as the inherit line is=20 on one line of it's own. (unconditionally) These rules that would=20 allready be followed out of style reasons would make various kinds of=20 parsers able to parse them. > Only time this would be required is if we move away from bash; if that > occurs, then I'd think a new extension would be required. It would allow to for example restrict the ebuild format such that initial= =20 parsing is not done by bash (but the files are still parseable by bash).=20 If we perform changes I think it should be done right in the first place. > As is, shifting the 'template' loaded for an ebuild can be done in > ebd's init_environ easy enough, so no reason to add the extra > restrictions/changes. One of the issues of ebuilds is the cache/metadata stuff. Parsing an=20 ebuild for basic information takes a lot of time. This can be done lots=20 faster with a less featured parser (I've written one some day) that=20 accepts 98% of all current ebuilds, just doesn't like dynamic features in=20 the toplevel. Such a parser could be a python plugin and as such easy to=20 use from python. However to ensure compatibility with a faster parser the=20 EAPI variable should be there in a way that is a little more strict than=20 the other variables. And such a restriction is in practice not a=20 restriction. The restriction I propose would be: =2D If EAPI is defined in the ebuild it should be unconditional, on it's own line in the toplevel of the ebuild before any functions are defined. (preferably the first element after the comments and whitespace) =2D If EAPI is not defined in the ebuild, but in an eclass, the inherit chain should be unconditional and direct. Further more in the eclass the above rules should be followed. Please note that many of the conditions are allready true for current=20 ebuilds, just portage can "handle" more. Paul =2D-=20 Paul de Vrieze Gentoo Developer Mail: pauldv@gentoo.org Homepage: http://www.devrieze.net --nextPart12513654.VdYEYWWfmb Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQBDDZ6YbKx5DBjWFdsRAqa7AKCLCZ35M5RLGes8xS7fXyetpseLGwCeKpVV tyf63I99PG0+RhiUrgDiSm0= =fqWG -----END PGP SIGNATURE----- --nextPart12513654.VdYEYWWfmb-- -- gentoo-dev@gentoo.org mailing list