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 1K6Ih8-0004Vi-OQ for garchives@archives.gentoo.org; Wed, 11 Jun 2008 05:16:26 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id EA601E0401; Wed, 11 Jun 2008 05:16:24 +0000 (UTC) Received: from rv-out-0708.google.com (rv-out-0708.google.com [209.85.198.249]) by pigeon.gentoo.org (Postfix) with ESMTP id 94150E0401 for ; Wed, 11 Jun 2008 05:16:24 +0000 (UTC) Received: by rv-out-0708.google.com with SMTP id b17so2878949rvf.46 for ; Tue, 10 Jun 2008 22:16:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=QP6BbO47txBqlVKJAtkXfNSIsVDFjCpXcdm1ChWKyxA=; b=GR5o9Tu8EJSm9vnylVi80GoGKi4RXray7prr5C8ti2o/4ThjA0frdpqugq6QsSBPxU 7dr/jq4roZecGwq9kXdAgVKuF6v8p5PIkmLBgxod2WwJJ2mqWGs2YZykWpUAgUEEtJz1 ruzLstfaQOtt5OOsXHzYg+cUfqdk2dQYVPhkY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=P6QmSypFkEmK3pFLIloPQcyQ+vS/MwlOmZV3cgCIHfMis7M3OzyQCbUpdD/l0wx/+g IfHugQpZuN1PRrrpM5qK0r2o9b8cLaej4pVpSAl8wzW1CfelpDmTDPKrHA4WajuNm8Bx yTLa6D7ZglJSZm1HXQyYnGnjx9IPwGdbxqCeY= Received: by 10.114.122.5 with SMTP id u5mr5967752wac.66.1213161383313; Tue, 10 Jun 2008 22:16:23 -0700 (PDT) Received: from seldon ( [208.68.109.98]) by mx.google.com with ESMTPS id m29sm17774725poh.4.2008.06.10.22.16.22 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 10 Jun 2008 22:16:22 -0700 (PDT) Date: Tue, 10 Jun 2008 22:16:21 -0700 From: Brian Harring To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] extending existing EAPI semantics Message-ID: <20080611051621.GF9494@seldon.metaweb.com> References: <20080611025622.GA9494@seldon.metaweb.com> <20080611042004.6d411d8e@googlemail.com> <20080611033311.GC9494@seldon.metaweb.com> <20080611043801.1b4954d7@googlemail.com> <20080611041036.GE9494@seldon.metaweb.com> <484F53D3.1060003@pioto.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: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="s5/bjXLgkIwAv6Hi" Content-Disposition: inline In-Reply-To: <484F53D3.1060003@pioto.org> User-Agent: Mutt/1.5.13 (2006-08-11) X-Archives-Salt: 8e5a8e6f-669c-46ed-936b-94a6bb57a68b X-Archives-Hash: a6d43fac1bab4ead71701b9bfbbb6317 --s5/bjXLgkIwAv6Hi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable You actually pretty much completely misinterpreted what I was saying,=20 so inserting the example back into the email and trying again... On Wed, Jun 11, 2008 at 12:25:55AM -0400, Mike Kelly wrote: > Brian Harring wrote: > >One thing I'll note is that the .ebuild-$EAPI approach isn't the end=20 > >all fix to versioning extensions that y'all represent it as. =20 > >Essentially, what .ebuild-$EAPI allows is additions to version=20 > >comparison rules, no subtractions. Each new $EAPI *must* be a=20 > >superset of previous $EAPIs. > > >An example would be removal of float comparison rules; for=20 > ><=3Deapi-1, .006 < .6; Now if eapi-2 stated .006 =3D=3D .6, that=20 > >literally means that the PM would have to maintain versioning rules=20 > >per eapi level, meaning that for an eapi1 ebuild, what it would=20 > >match would differ from eapi2. Aside from that being a=20 > >cluster-fuck in the implementation, it's a cluster-fuck for the dev=20 > >trying to visualize what the manager is actually up to. > > Uhh... no. Just like how older package managers which don't understand=20 > how to read the EAPI from a filename suffix would basically ignore the=20 > new ebuilds, any package manager that can, but doesn't recognize the=20 > eapi of the new one, will just ignore it. It won't ever try to figure=20 > out its version or anything, it'll just do nothing. Here's the scenario: 1) EAPI1 defines foo-0.006 < foo-0.6. 2) EAPI2 redefine it so that foo-0.006 =3D=3D foo-0.6 3) pkg 'a' has one version- '0.006' 4) pkg b-1, EAPI=3D1; DEPEND=3D'<=3Da-0.006' 5) pkg c-1, EAPI=3D2; DEPEND=3D'>=3Da-0.6' Now, via EAPI1 definition, b-1 *must* match a-0.006; via EAPI2=20 definition, b-2 *must* match a-0.006 also. The only way the manager=20 can properly support this request is via getting the EAPI from the pkg=20 that specified that request. Literally, the ordering of matches would have to vary dependant upon=20 the eapi of the pkg. This is a serious cluster fuck for any=20 implementation, and it's a pretty nice gotcha for ebuild developers. The sane alternative here is that each successive EAPI release,=20 specifically the versioning rules, must be a superset of existing. =20 Via that you can induce a total ordering that works regardless of the=20 EAPI level of the generating pkg. A scenario that is far more entertaining is how the manager is=20 supposed to handle the following: 1) EAPI2 defines 1.0-scm > 1.0 2) pkg 'a' has one visible version; 1.0-scm 3) pkg b-1 EAPI=3D1, DEPEND=3D'<=3Da-1' 4) pkg c-1 EAPI=3D2, DEPEND=3D'a' What is the correct result here? Since b-1's versioning rules don't=20 know a damn thing about -scm, should it even be possible for it to use=20 that version? The only valid solution here (since EAPI1 does not=20 know, nor specify the ordering of -scm) is to bail. If you're maintaing a total ordering (each EAPI a superset of the=20 last for versioning rules), you *could* retroactively decide on that=20 case. Either way, point is that .ebuild-$EAPI doesn't magically solve=20 versioning changes. It hides away user visibility of it, but doesn't=20 solve the real issue. > Also, there is absolutely no reason for all future EAPIs to be a=20 > superset of old eapis. =2Eebuild-$EAPI-n requires all *versioning rules* to be a superset of=20 $EAPI=3D(n-1); if in doubt, re-read my example above. Non versioning rules of $EAPI, no, no requirement to be supersets of=20 proceeding- but versioning under .ebuild-$EAPI, yes, it's required. Cheers, ~harring --s5/bjXLgkIwAv6Hi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFIT1+ksiLx3HvNzgcRAigjAKCppclXcWspB1l5GohPps2cK3oN2QCeMPNm Aj8w3oNYUDtmEHNR1iX2Ym8= =AeQv -----END PGP SIGNATURE----- --s5/bjXLgkIwAv6Hi-- -- gentoo-dev@lists.gentoo.org mailing list