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 1KIEoE-0003fz-JI for garchives@archives.gentoo.org; Mon, 14 Jul 2008 03:33:06 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 39699E04AB; Mon, 14 Jul 2008 03:33:05 +0000 (UTC) Received: from smtp-vbr5.xs4all.nl (smtp-vbr5.xs4all.nl [194.109.24.25]) by pigeon.gentoo.org (Postfix) with ESMTP id EFB66E04AB for ; Mon, 14 Jul 2008 03:33:04 +0000 (UTC) Received: from epia.jer-c2.orkz.net (atwork-106.r-212.178.112.atwork.nl [212.178.112.106]) (authenticated bits=0) by smtp-vbr5.xs4all.nl (8.13.8/8.13.8) with ESMTP id m6E3X4bY014844 for ; Mon, 14 Jul 2008 05:33:04 +0200 (CEST) (envelope-from jer@gentoo.org) Date: Mon, 14 Jul 2008 05:32:58 +0200 From: Jeroen Roovers To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Council meeting summary for 10 July 2008 Message-ID: <20080714053258.44ba9a59@epia.jer-c2.orkz.net> In-Reply-To: <20080714022235.2cfb0a2c@googlemail.com> 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> X-Mailer: Claws Mail 3.5.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: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner X-Archives-Salt: f45c6cb4-cd7e-4d3f-a94c-f29096ba38df X-Archives-Hash: 92369637e87adde2746fd6789c817da0 On Mon, 14 Jul 2008 02:22:35 +0100 Ciaran McCreesh wrote: > 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. > > > > 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. I'm sorry to say this, but I actually do take offence at most things you write. > As you know fine well, implementing what clearly should be 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. > 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. 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. > And making sure such functionality can come along is at least partly > the Council's responsibility. So that's one count of "nice, elegant", and apparently that is what you feel opposes "doing them badly"? > > 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. 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. > 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. [Class _of_ improvements, I guess.] 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. 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). 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 =cat/pkg-ver. 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. I grant you that on the surface it really does look nice and elegant. JeR -- gentoo-dev@lists.gentoo.org mailing list