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 1KICm6-0001cQ-9O for garchives@archives.gentoo.org; Mon, 14 Jul 2008 01:22:46 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 84C30E027F; Mon, 14 Jul 2008 01:22:44 +0000 (UTC) Received: from ik-out-1112.google.com (ik-out-1112.google.com [66.249.90.177]) by pigeon.gentoo.org (Postfix) with ESMTP id 2D00EE027F for ; Mon, 14 Jul 2008 01:22:44 +0000 (UTC) Received: by ik-out-1112.google.com with SMTP id c21so2150966ika.2 for ; Sun, 13 Jul 2008 18:22:43 -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=J9astl8BToxWnuR/5R+X5lGp1sHJO3nNx7LPZpai45E=; b=Hy5aVqRB0rR2fzaOKbF6xfETR05pZj8p+RVv7m3X4S8UFi1I0uf9ti76BGbzel1Szw bVr5R5H3/+wZ9k8d+xsSh2MLrmxHGx7+XUM4nMyUkV0/48Nbq4V90Zbl1YVv6iOXt+Hr jgJk1HuLJohVPzuRrvWmRo0SFaBLOl0P2hvdQ= 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=ulMn7m+KT12j3Y78kassH8D2rP0a0mvkxYxuEqq6IhcdXET/5s7pclKB4DKbvS5LEz M+SavdV7LfJTb55VykqqHG7cFLAM5e5XD1Q1vbfwNFil7r98z9wqQqY52fsmZ1F9Sakp jw0JJ6iq2Rawg0cqs24L1ilvH/Web6ZoIVwkM= Received: by 10.210.71.11 with SMTP id t11mr8532737eba.105.1215998563321; Sun, 13 Jul 2008 18:22:43 -0700 (PDT) Received: from localhost ( [92.235.187.79]) by mx.google.com with ESMTPS id b36sm5701502ika.5.2008.07.13.18.22.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 13 Jul 2008 18:22:43 -0700 (PDT) Date: Mon, 14 Jul 2008 02:22:35 +0100 From: Ciaran McCreesh To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Council meeting summary for 10 July 2008 Message-ID: <20080714022235.2cfb0a2c@googlemail.com> In-Reply-To: <20080714031344.3c629b2c@epia.jer-c2.orkz.net> References: <20080713071118.GC1891@comet> <20080713235255.0e2b7f8e@googlemail.com> <20080714002117.731f1408@googlemail.com> <20080714004306.727d20df@googlemail.com> <20080714031344.3c629b2c@epia.jer-c2.orkz.net> X-Mailer: Claws Mail 3.4.0 (GTK+ 2.12.9; i686-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; boundary="Sig_/IKzP+UA1I7.My.GCD.FJ/+Y"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-Archives-Salt: 7a8476b0-ca4c-47e5-9ad7-130a7ee76148 X-Archives-Hash: 1ef08606ce7de1263e898c319d2ae151 --Sig_/IKzP+UA1I7.My.GCD.FJ/+Y Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 14 Jul 2008 03:13:44 +0200 Jeroen Roovers wrote: > On Mon, 14 Jul 2008 00:43:06 +0100 > Ciaran McCreesh wrote: > > People are already doing those other things, and doing them badly, > > because there's currently no other option. This isn't some > > hypothetical future requirement. >=20 > When you wrote "doing them badly", did you mean to imply doing > something else than GLEP 55, or were you just slagging off whoever > implemented eblits in sys-libs/glibc? As much as you like to try to find some way of taking offence at everything I write, no, there's no slagging off in there. As you know fine well, implementing what clearly should be package manager provided functionality as hacks in an ebuild is never going to give a nice, elegant solution. However, if package manager functionality isn't available and can't become available quickly, it might be the only solution until such functionality can come along. And making sure such functionality can come along is at least partly the Council's responsibility. > In other words perhaps, is it your opinion that GLEP 55 needs to be > implemented because sys-libs/glibc requires an immediate rewrite? Are > there any bug reports that would be good examples of why this new > implementation is warranted? GLEP 55 wouldn't even allow an immediate rewrite of glibc because new EAPIs can't easily be used on system packages. So no. Instead, GLEP 55 would allow a future EAPI to introduce a proper per-package eclass-like solution at the package manager level, which could then over time be phased into glibc, and over less time be phased into other packages that would make use of it. That's the nice thing about the GLEP -- it allows the phased introduction of a larger class improvements without major upheaval. --=20 Ciaran McCreesh --Sig_/IKzP+UA1I7.My.GCD.FJ/+Y Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkh6ql4ACgkQ96zL6DUtXhHvdACgh+3tBdqVjfng6WU9c2GpN37T 7aQAoJ+LaHZAHa4rwpR1No8r0vBdr23a =Cr8p -----END PGP SIGNATURE----- --Sig_/IKzP+UA1I7.My.GCD.FJ/+Y-- -- gentoo-dev@lists.gentoo.org mailing list