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 1OhRXa-00081m-Ph for garchives@archives.gentoo.org; Fri, 06 Aug 2010 18:21:11 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 17FF5E081F; Fri, 6 Aug 2010 18:21:05 +0000 (UTC) Received: from mail-pw0-f53.google.com (mail-pw0-f53.google.com [209.85.160.53]) by pigeon.gentoo.org (Postfix) with ESMTP id EA471E0A52 for ; Fri, 6 Aug 2010 18:20:50 +0000 (UTC) Received: by pwj2 with SMTP id 2so953848pwj.40 for ; Fri, 06 Aug 2010 11:20:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:date:from:to:subject :message-id:references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=tRBzzGB0AaJcscUe4qqLYCwT91vqr6+f6GZSjwu/rDI=; b=a/65yex/0rjJ0dcs5xajqo7G9+8X9iCVfwlRh9VDPauhL9qe6d9pHDHNUfFCpk2CjA se7PwcKP33D8jZd9fKoFgIrn2b5blCF2J3NYLws3cYJ7YqM40FRSJ4H6Dq7/jluzrzx/ QHSg2+d7qwWvjQPAIJvIhxGEb374KuWKRK18Y= 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=teUe35PHy6vZEgSIytKZXLnWPVcZMDQFioZJHmfQ7Uu/zVyWK8GGEsGdJToRnPpHzG WUOkMAaXSB+OqsanV6vmsBj0FE0MJGZbZlkqMdFmT67i6BJjkcNE6872uROl0ozU2Ool aWU6pXoojNWVCsy6sgmoA0GCNXy21BPB1zQS8= Received: by 10.114.72.9 with SMTP id u9mr14399873waa.137.1281118850414; Fri, 06 Aug 2010 11:20:50 -0700 (PDT) Received: from smtp.gmail.com (c-67-171-128-62.hsd1.wa.comcast.net [67.171.128.62]) by mx.google.com with ESMTPS id 33sm3280568wad.6.2010.08.06.11.20.46 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 06 Aug 2010 11:20:48 -0700 (PDT) Received: by smtp.gmail.com (sSMTP sendmail emulation); Fri, 06 Aug 2010 11:18:46 -0700 Date: Fri, 6 Aug 2010 11:18:46 -0700 From: Brian Harring To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] RFC: Reviving GLEP33 Message-ID: <20100806181846.GB17578@hrair> References: <4C569638.9000407@gentoo.org> <20100802211517.1f207d31@snowcone> <4C573EBB.3080005@gentoo.org> <20100805032702.GG12708@hrair.al.intel.com> <20100806172732.GA17578@hrair> <20100806184831.252c7a8f@snowcone> 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="EuxKj2iCbKjpUGkD" Content-Disposition: inline In-Reply-To: <20100806184831.252c7a8f@snowcone> User-Agent: Mutt/1.5.20 (2009-06-14) X-Archives-Salt: 3e45307e-1443-4b4b-8f15-94981ab958f7 X-Archives-Hash: b8b6aeca82a37f5f31e5ec415c70d220 --EuxKj2iCbKjpUGkD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 06, 2010 at 06:48:31PM +0100, Ciaran McCreesh wrote: > 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. >=20 > 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. > You appear to be confusing "providing a better replacement that we can > use immediately that doesn't have any of these problems" with > "bitching". > That's ok. We can migrate to an even better solution now. And by "right now", I assume you meant to say "minimally a year down=20 the line after a portage is stabled supporting g55 semantics and=20 resolving any breakage it's usage induces". You know, the same issue=20 EAPI itself had to go through to ensure that people had a reasonable=20 chance of getting an appropriate error message and support being in=20 place. Accuracy in details is very useful, including stating the full picture=20 rather than just the parts you think sell your particular view. > The *fact* is, you can't use new version formats with any of your > proposals, New version formats aren't magically usable the moment g55 lands. At=20 the very least you're forgetting about bundled glsa's and their=20 knowledge of atom formats. Suppose the next comment will be "they suck, throw them out", but so=20 it goes. Realistically, 'the fact is' that a specific scm tag is preferable to=20 -9999. The reality is that people and the tools have been working=20 around it without huge issues for a long while. Would it be nice having some -scm tag? Sure. Is it worth the=20 disruption impementing it, and it's dependencies requires? That=20 arguement you've still not managed to convince people of. > 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. The restrictions are "no new global functionality can set or influence=20 EAPI". Basically the same restriction you forced on eclasses. It's=20 nasty and arbitrary when I state it, but some how it is sane when you=20 propose it the same thing? The thing you're ignoring out of this g55 idiocy is that people don't=20 particularly seem to want it. There has been an extremely vocal=20 subgroup of paludis/exherbo devs pushing for it while everyone else=20 seems to have less than an interest in it. That's generalizing a bit,=20 but is reasonably accurate. Pretty much, scream all you want, if people don't like it it's not=20 going to go anywhere. So... keep fighting windmills, or do something=20 useful and use what is available to you (existing EAPI semantics). _EITHER WAY_, rather than having g33 get beat down for unrelated=20 reasons by people screaming they want their pony/g55, g33 can proceed=20 despite claims to the contrary, and it doesn't require g55 as=20 ciaran/crew have claimed. Split a thread if you really want to rehash g55 also, rather than the=20 thread jacking that is underway. ~brian --EuxKj2iCbKjpUGkD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) iEYEARECAAYFAkxcUgYACgkQsiLx3HvNzgfUQwCbBAXeAjnnqMtbeI4C8Ur/Pypy luIAn047R5AS/eJQHLNQkFryrTy6r5da =SW8L -----END PGP SIGNATURE----- --EuxKj2iCbKjpUGkD--