From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1Is60z-0005E3-Tj for garchives@archives.gentoo.org; Wed, 14 Nov 2007 00:21:58 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.14.2/8.14.0) with SMTP id lAE0L3TH026714; Wed, 14 Nov 2007 00:21:03 GMT Received: from mail.twi-31o2.org (c-24-6-168-204.hsd1.ca.comcast.net [24.6.168.204]) by robin.gentoo.org (8.14.2/8.14.0) with ESMTP id lAE0IMs2023069 for ; Wed, 14 Nov 2007 00:18:23 GMT Received: from localhost (localhost [127.0.0.1]) by mail.twi-31o2.org (Postfix) with ESMTP id 9733A17B9971 for ; Wed, 14 Nov 2007 00:18:22 +0000 (UTC) X-Virus-Scanned: amavisd-new at twi-31o2.org Received: from mail.twi-31o2.org ([127.0.0.1]) by localhost (gravity.twi-31o2.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wqwPWwOpwBNX for ; Wed, 14 Nov 2007 00:18:15 +0000 (UTC) Received: from [192.168.100.60] (dsl211-165-131.sfo1.dsl.speakeasy.net [74.211.165.131]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.twi-31o2.org (Postfix) with ESMTP id CC93B17B8060 for ; Wed, 14 Nov 2007 00:18:14 +0000 (UTC) Subject: Re: [gentoo-dev] RFC: Place of EAPI variable in ebuild From: Chris Gianelloni To: gentoo-dev@lists.gentoo.org In-Reply-To: <20071113203136.6133ba49@blueyonder.co.uk> References: <4734D767.1080900@gentoo.org> <20071109220724.GK19739@gentoo.org> <47375195.9060400@gentoo.org> <1194985323.8302.14.camel@inertia.twi-31o2.org> <20071113203136.6133ba49@blueyonder.co.uk> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-tysGkCEDnumLdiTT//fx" Date: Tue, 13 Nov 2007 16:17:59 -0800 Message-Id: <1194999479.8302.57.camel@inertia.twi-31o2.org> 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 X-Mailer: Evolution 2.12.1 X-Archives-Salt: cc0e7caf-a15a-422d-96ae-4cf05366b654 X-Archives-Hash: ac0587b6f112f4e33696a49a9f6f276a --=-tysGkCEDnumLdiTT//fx Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2007-11-13 at 20:31 +0000, Ciaran McCreesh wrote: > That was only the case because previously, using new features that > Portage didn't support would cause horrible breakage. Now, instead, the > ebuilds show up as being masked. ...which is just as good as "broken" when it happens to a new user first installing Gentoo and wondering why he can't even follow the directions in the Handbook. What brought me to bring this up was the mention of changing of eclasses which support a large number of ebuilds, effectively masking a significant portion of the tree from our users. Let's say that I added EAPI=3D1 to eutils.eclass because I wanted to use some new EAPI=3D1 feature in one of the functions. Guess what? I've now managed to mask *portage* for users of older portage versions. In fact, I've managed to mask paludis and pkgcore, too. Yes, this is an extreme example. Yes, it is completely possible. Yes, that user would be completely screwed. > > Now, this isn't so much of an issue with individual ebuilds, but > > you're talking about changing how the Java eclasses work, essentially > > blocking *anyone* using an older portage (including everyone > > installing from 2007.0 media) from using any package which inherits > > the eclass. >=20 > They just need to upgrade their package manager first. Easy. Expecting users to do pretty much anything on their own is broken behavior and should not be relied on for package manager compatibility. > > Also, we should really think about this sort of thing before we start > > using it. How are we going to support EAPI changes in eclasses? What > > if I have an eclass with EAPI=3D1 features and I want to add some EAPI= =3D2 > > features? I think allowing EAPI=3D* globally in an eclass should be > > prohibited, unless the *entire* eclass is planned for EAPI=3D* ebuilds, > > only. >=20 > Doing an entire eclass for one specific EAPI generally isn't a good idea > since it's fairly likely that EAPI bumps will be a fairly common thing. >=20 > > In other words, you'd need new EAPI=3D1 eclasses for your EAPI=3D1 > > ebuilds. Either that, or some way to say something like: "execute > > code path A for EAPI=3D0 and execute code path B for EAPI=3D1" or > > something similar. I would suspect that the "best" current solution > > is to check EAPI in the individual functions and perform the right > > actions based on those functions, rather than marking an entire > > eclass. After all, only EAPI=3D* functions need to be "hidden" behind > > EAPI. >=20 > A solution with EAPI-agnostic code in foo-common.eclass and > EAPI-specific code in foo.eclass, foo-eapi1.eclass etc is probably more > readable and maintainable in most cases. Umm... So in the paragraph above, you say an EAPI-specific eclass isn't a good idea, and here you push it as the proposed solution. Huh? Consistency, please... I guess my real point is that we need to be *really* careful when using this stuff. It is *not* as simple as you make it out to sound. All it takes is one person adding an EAPI into an eclass somewhere to completely screw over a *huge* number of our users. I am just trying to point this out and hopefully get discussion going on how to utilize these great new features without potentially causing damage to our user's machines and our reputation. I still think that EAPI should not be allowed to be set in an eclass globally. All I can see is it causing problems for tons of users who don't have a clue what is happening to their systems. --=20 Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Foundation Trustee Gentoo Foundation --=-tysGkCEDnumLdiTT//fx Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQBHOj63kT4lNIS36YERArv+AJ9WBo4xyiDBn75jmcSWeFJRqbniwgCgsR7x sXS5BgsfMRe5Da16ywbEVX4= =O5LV -----END PGP SIGNATURE----- --=-tysGkCEDnumLdiTT//fx-- -- gentoo-dev@gentoo.org mailing list