On Mon, 14 Jul 2008 02:22:35 +0100
Ciaran McCreesh <ciaran.mccreesh@...> wrote:

> On Mon, 14 Jul 2008 03:13:44 +0200
> Jeroen Roovers <jer@g.o> wrote:
> > On Mon, 14 Jul 2008 00:43:06 +0100
> > Ciaran McCreesh <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@g.o mailing list