From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1OhR2R-0004ib-To for garchives@archives.gentoo.org; Fri, 06 Aug 2010 17:49:00 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 1F326E09E9; Fri, 6 Aug 2010 17:48:57 +0000 (UTC) Received: from mail-ew0-f53.google.com (mail-ew0-f53.google.com [209.85.215.53]) by pigeon.gentoo.org (Postfix) with ESMTP id DB375E09C1 for ; Fri, 6 Aug 2010 17:48:46 +0000 (UTC) Received: by ewy19 with SMTP id 19so3580391ewy.40 for ; Fri, 06 Aug 2010 10:48:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type; bh=LeLEieJX+gw1nC5t58oC92KChuWdc5ZgcA2kFuoxe5I=; b=fIGqM2Q6oCTOczik2qbahFnSLfhU5Zk9qBvU+jkH+et2x1FYM89smiBSbQlQ7OYrnc NAyd99jHg8KG2BBhOPYmyb+t5fNRT4vD14BfWEAE7oF2+xlsoU1iCyNXOrmAoQysGlVZ BCXe0QlCcG27EsS/bmv5a3LjESUVrJcHQm3TI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; b=liA3CuMp0I7/E/ZB366Pt1YQ9hW3/RMM+zAW1wSDJ6B1tEeHJ8yvnkObuGm0nVWdeQ AvNV/ODoUxV6HLN30py59Tf3/7/PAnsx97oJ/kWr0BlcV6/OSfwGXH/lvBwS7byjoWVR rVzAGCXZfnP9YvPjGGGYcc9SOfU6BTo5mRdIM= Received: by 10.213.31.134 with SMTP id y6mr9067071ebc.82.1281116926193; Fri, 06 Aug 2010 10:48:46 -0700 (PDT) Received: from snowcone ([92.16.26.237]) by mx.google.com with ESMTPS id z55sm2684775eeh.21.2010.08.06.10.48.45 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 06 Aug 2010 10:48:45 -0700 (PDT) Date: Fri, 6 Aug 2010 18:48:31 +0100 From: Ciaran McCreesh To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] RFC: Reviving GLEP33 Message-ID: <20100806184831.252c7a8f@snowcone> In-Reply-To: <20100806172732.GA17578@hrair> References: <4C569638.9000407@gentoo.org> <20100802211517.1f207d31@snowcone> <4C573EBB.3080005@gentoo.org> <20100805032702.GG12708@hrair.al.intel.com> <20100806172732.GA17578@hrair> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; x86_64-pc-linux-gnu) 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; boundary="Sig_/LRh+_pK8.ED23sf.+oZ=GAb"; protocol="application/pgp-signature" X-Archives-Salt: 24d6a6b2-5e48-459d-95cc-e0810691e7ee X-Archives-Hash: 49fac11c2c8e3f7f7c82113541b91b15 --Sig_/LRh+_pK8.ED23sf.+oZ=GAb Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Fri, 6 Aug 2010 10:27:32 -0700 Brian Harring wrote: > As for 'blatant hack', if you've got no users nor preexisting ebuild=20 > data, you can design whatever you want- it's quite easy to call > things blatant hacks if you can design things from scratch and not > worry about compatibility. This is a form of armchair quarterbacking. No it isn't, since we've proposed a working alternative that doesn't have any of the defects that EAPI in its current form does. > EAPI did not have that luxury however, thus a pragmatic solution was=20 > choosen. I've heard a lot of bitching from various folk about EAPI=20 > over the years, but the fact is even with it's flaws (both in=20 > process, people involved, and in original constraints) it still has=20 > been rolling changes out- all the while without requiring people to=20 > rewrite ebuilds from scratch, or continually track an unversioned=20 > format that changes semi-monthly. You appear to be confusing "providing a better replacement that we can use immediately that doesn't have any of these problems" with "bitching". > It'd be nice if people were to remember that rather than spending=20 > their time bitching about it. Hindsight, I'd have done a few things=20 > differently, but that's the nature of hindsight- specifically I=20 > would've used an eapi function rather than var. That's ok. We can migrate to an even better solution now. > Whether said people like it or not, it was a known decision at the=20 > time of creation- including the scenario under discussion. One thing=20 > you'll note about my posts is that I'll list out what is possible,=20 > and state what should/shouldn't be done. Just because I personally=20 > think something is complete shit doesn't mean I go telling folk it's=20 > impossible. There's a difference between opinion and fact- you're=20 > excusing opinion stated as fact, which is not correct. Fact is, this=20 > technique does work even if certain folk have another approach they=20 > want instead. The *fact* is, you can't use new version formats with any of your proposals, and using new global scope functionality or new bash functionality introduces all kinds of nasty difficulties and arbitrary restrictions of which developers have to be intimately aware. --=20 Ciaran McCreesh --Sig_/LRh+_pK8.ED23sf.+oZ=GAb Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) iEYEARECAAYFAkxcSvgACgkQ96zL6DUtXhGq5wCaA9TJa0OTsHZGSdLbTHZVDJfx +lYAn0IegEvhYiuBluxw8aYB13EyBoBx =LIq0 -----END PGP SIGNATURE----- --Sig_/LRh+_pK8.ED23sf.+oZ=GAb--