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 1KINNX-0001sO-9Q for garchives@archives.gentoo.org; Mon, 14 Jul 2008 12:42:07 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 37DECE04D1; Mon, 14 Jul 2008 12:42:05 +0000 (UTC) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by pigeon.gentoo.org (Postfix) with ESMTP id D2D2FE04D1 for ; Mon, 14 Jul 2008 12:42:04 +0000 (UTC) Received: by ug-out-1314.google.com with SMTP id z27so236665ugc.49 for ; Mon, 14 Jul 2008 05:42:04 -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=YU1zSpGvOmYcoTgjHiLLehwXSxXhN0RCOOsXdFoTrsI=; b=vCUInTfWZHyQSKHXii3b2TmRMiGe0YaZp0JMv0GJKflew+DJ3dnwE4qqctt88tobyo biPre4JapCtYU8WIHgf9OEBz6iB69FAit9KCFHq6WgZ8PqCCG+kfEZ4imUMxpzeg+hIH XeUMHDJ4243nna3mNhMUhw0Oifbs6t/GySdbY= 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=CHU20KD9Ix3McYZfR909v3//B6andhJ1YRvvgZjcRf/TbavU2YrmYaBNLzuBENE/nu 52YrS4x9OlpihfBEhY+O51qJB2E8c2E2CUcJ/nTqTWekx8gFUs9gtKnERs5d6yBjwHsN 3YlS2D8GZhNcaKhgLSn2TXUyCwXiwfbzDtVZ8= Received: by 10.66.250.17 with SMTP id x17mr1679768ugh.0.1216039323916; Mon, 14 Jul 2008 05:42:03 -0700 (PDT) Received: from snowcone ( [92.235.187.79]) by mx.google.com with ESMTPS id 19sm6413634ugl.66.2008.07.14.05.42.03 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 14 Jul 2008 05:42:03 -0700 (PDT) Date: Mon, 14 Jul 2008 13:41:58 +0100 From: Ciaran McCreesh To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Council meeting summary for 10 July 2008 Message-ID: <20080714134158.5fb3b130@snowcone> In-Reply-To: <20080714053258.44ba9a59@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> <20080714022235.2cfb0a2c@googlemail.com> <20080714053258.44ba9a59@epia.jer-c2.orkz.net> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.10; 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; boundary="Sig_/A.9D4XJ.1hcpfYYCJS6ZvXx"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-Archives-Salt: 7a369092-b465-4a77-ad40-c8525f9e2b92 X-Archives-Hash: 3db763b9751cb3aab685a81385efb859 --Sig_/A.9D4XJ.1hcpfYYCJS6ZvXx Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 14 Jul 2008 05:32:58 +0200 Jeroen Roovers wrote: > I'm sorry to say this, but I actually do take offence at most things > you write. Perhaps you should consider what that indicates about yourself, rather than about me. > > As you know fine well, implementing what clearly should be >=20 > Please stop assuming people know everything you know and/or that > people should know everything you know. This is a public forum where > you should undertake to explain yourself fully instead of referring > vaguely to an unknown set of morals and then suggesting another party > should address whatever conflicts with that. It is a particularly > subtle variant of the classic straw man that you regularly wield, and > it is one of those things that often makes me take offence at what > you write. All I'm assuming is that people have read and understood the GLEP, and in any places where they don't understand, they ask. Is that assuming too much? > > 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. >=20 > So it's not "doing them badly", it's currently the only solution and > you haven't provided any arguments against this only solution as yet. No, it is doing it badly. A square wheel is bad, even if it was necessary because the round one was unattainable. > > > 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? > >=20 > > GLEP 55 wouldn't even allow an immediate rewrite of glibc because > > new EAPIs can't easily be used on system packages. >=20 > Oh. You just shot down your only real world example (eblit versus GLEP > 55). If you have any more, I'd happily have a look at them, as would > anyone else worrying about the consequences of having GLEP 55 > implemented. Uh. Future versions of glibc? Read what I wrote. > > 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 > [Class _of_ improvements, I guess.] >=20 > Please provide an example of what that process would look like. You've > always been good at these "we have ebuild 1, then ebuild 2 comes > along, depending on ebuild 3 [...]" games, so please explain what > we'd end up with in a hypothetical GLEP 55 compliant > gentoo-x86/sys-libs/glibc, with "build files" (formerly ebuilds) > getting added, removed, keyworded, package.masked and so on. New, experimental glibc versions that aren't expected to go stable quickly use the new EAPI. Existing versions and any "will need to go stable soon" bumps stay using the old EAPI. After the next release (which is *only* an issue for dependencies of the package manager) all new glibc versions use the new EAPI. > What _I_ envision now is a motley crew of EAPI suffixed "build files" > processing through gentoo-x86/sys-libs/glibc over time. Surely it > would look a right mess every time you needed to go into that > directory (particularly not in a role as any package manager's user or > developer, but as a "build file" developer browsing through those > files). How does: $ ls ChangeLog glibc-2.3.6-r4.ebuild glibc-2.5.1.ebuild Manifest glibc-2.3.6-r5.ebuild glibc-2.6.1.ebuild files glibc-2.4-r4.ebuild glibc-2.6.ebuild glibc-2.2.5-r10.ebuild glibc-2.5-r2.ebuild glibc-2.7-r2.ebuild glibc-2.3.2-r12.ebuild glibc-2.5-r3.ebuild glibc-2.8_p20080602.ebuild-2 glibc-2.3.5-r3.ebuild glibc-2.5-r4.ebuild metadata.xml look any worse than what's there now? > What GLEP 55 fails to address right now is the very development > process it is seemingly supposed to alleviate. It addresses the issue > of EAPI implementation from the viewpoint of the package manager's > developer, but it doesn't begin to address the viewpoint of the > package maintainer or architecture developer at all. It looks to me > like a lot of problems are moved out of the package manager(s) and > into this already huge tree of files, with different EAPI-suffixed > files addressing different problems, and that indicate be a > non-trivial increase in the number of files in the tree - files which > would address the equal purpose of installing exactly one > =3Dcat/pkg-ver. GLEP 55 does not change the EAPI process from a maintainer perspective, except that it replaces "set EAPI=3DX in the ebuild" with "use .ebuild-X". > In other words, disregarding its other real world deficiencies like an > immediate goal, GLEP 55 fails to describe a keywording policy for > architecture developers and it fails to describe a "build file" > addition (bump) policy for package maintainers. There *is* no change there. --=20 Ciaran McCreesh --Sig_/A.9D4XJ.1hcpfYYCJS6ZvXx Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkh7SZgACgkQ96zL6DUtXhF+mgCZAcxEPNrPc1zffDBvF8fJnYJj WvsAoKA9RWtXSXwvhd7PT2yUSC6R4fAP =zWMB -----END PGP SIGNATURE----- --Sig_/A.9D4XJ.1hcpfYYCJS6ZvXx-- -- gentoo-dev@lists.gentoo.org mailing list