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 1EB7Kk-00056B-0v
for garchives@archives.gentoo.org; Fri, 02 Sep 2005 08:55:38 +0000
Received: from robin.gentoo.org (localhost [127.0.0.1])
by robin.gentoo.org (8.13.4/8.13.4) with SMTP id j828qREA022084;
Fri, 2 Sep 2005 08:52:27 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 j828qQkX030052
for <gentoo-portage-dev@lists.gentoo.org>; Fri, 2 Sep 2005 08:52:26 GMT
Received: from localhost (localhost [127.0.0.1])
by callisto.cs.kun.nl (Postfix) with ESMTP id AB1FA2E8029
for <gentoo-portage-dev@lists.gentoo.org>; Fri, 2 Sep 2005 10:53:06 +0200 (CEST)
From: Paul de Vrieze <pauldv@gentoo.org>
To: gentoo-portage-dev@lists.gentoo.org
Subject: Re: [gentoo-portage-dev] PATCH: initial EAPI awareness
Date: Fri, 2 Sep 2005 10:53:05 +0200
User-Agent: KMail/1.8.2
References: <20050827105357.GY1701@nightcrawler> <4317E2D0.2080401@gmail.com> <20050902060453.GD8478@nightcrawler>
In-Reply-To: <20050902060453.GD8478@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+cltLG<x1{H>q<;@$Y,=?utf-8?q?O=5C=24=0A=09Tm=23G6M?=,g![Q62J{na*S9d;R[^8pc%u\aiLqU@`kJtYl"^6pxdW
Precedence: bulk
List-Post: <mailto:gentoo-portage-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-portage-dev+help@gentoo.org>
List-Unsubscribe: <mailto:gentoo-portage-dev+unsubscribe@gentoo.org>
List-Subscribe: <mailto:gentoo-portage-dev+subscribe@gentoo.org>
List-Id: Gentoo Linux mail <gentoo-portage-dev.gentoo.org>
X-BeenThere: gentoo-portage-dev@gentoo.org
Reply-to: gentoo-portage-dev@lists.gentoo.org
MIME-Version: 1.0
Content-Type: multipart/signed;
boundary="nextPart2007773.kDd96YD0e5";
protocol="application/pgp-signature";
micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <200509021053.05581.pauldv@gentoo.org>
X-Archives-Salt: 2694b43b-9cdb-440e-bc6e-ed35646b8365
X-Archives-Hash: 981d18f3d1f19c23c47c379b99f87fc6
--nextPart2007773.kDd96YD0e5
Content-Type: text/plain;
charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
On Friday 02 September 2005 08:04, Brian Harring wrote:
>
> Like I've said, EAPI is ebuild specific. Ebuild is a format; eapi
> defines revisions of it, in my mind a minor revision of the ebuild 1
> format. Any form of loss of backwards compatability *should* be a
> different format, .ebuild2 for all I care.
The new proposed format loses backwards compatibility. If there is=20
backwards compatibility no new format or api version is needed. EAPI=20
should work on the python level, not only on the ebuild.sh level.
> Trying to use EAPI to allow for N different formats into one format is
> wrong from where I sit; you would need a container format for it,
> which ebuild wasn't designed for (nor is it easily extensible to be
> made so I posit).
No it would state that the eclass is 100% compatible with both by the=20
formats overlapping and the ebuild not threading outside the overlapped=20
area. Take for an example many simple kde applications. Those use the kde=20
eclass to do all the work and only contain a skeleton of variables=20
themselves. These ebuilds are compatible with both the current as the=20
proposed new API. When marked so, they could be used as EAPI=3D1 as soon as=
=20
the kde eclass is ported to EAPI=3D1. Similarly many eclasses do not=20
provide src_compile, and as such are compatible with both EAPI versions.
> EAPI's original specification was for handling addition of new funcs,
> different hooks in the ebuild; I prefer it remain as this. The core
> rewrite is format agnostic, if a new format is defined (whether a
> massively managled version of ebuild or flat out new), it's a seperate
> format and should be handled via the core, not via ebuild specific
> package handling.
EAPI now is going to be used for the above. It can however with very=20
little effort be made such that future ebuild format revisions are=20
possible. Also don't be mistaken that splitting out configure and make=20
stages do need support from the python part.
>
> There's no reason a repository can't hold multiple formats internally;
> the capability is there, use that rather then trying to jam too much
> into EAPI, imo at least.
How would you suggest to do this then. The ebuilds/eclasses are completely=
=20
the same except for their EAPI definition. They also have the same=20
(file)name. And that is not counting the fact that two files containing=20
the same is bad design as there will allways be an issue of one file=20
being updated and the other not.
Paul
=2D-=20
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net
--nextPart2007773.kDd96YD0e5
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQBDGBLxbKx5DBjWFdsRAmwtAJ47S6mkb8+mwjlgxXykwa6xJlt6OACg5Ek6
XsMPnDn/ai8gJbndFUkd1kA=
=XuyH
-----END PGP SIGNATURE-----
--nextPart2007773.kDd96YD0e5--
--
gentoo-portage-dev@gentoo.org mailing list