Re: [gentoo-dev] Council meeting summary for 10 July 2008

[Ciaran McCreesh <ciaran.mccreesh@googlemail.com>]

[-- Attachment #1: Type: text/plain, Size: 5420 bytes --]

On Mon, 14 Jul 2008 05:32:58 +0200
Jeroen Roovers <jer@gentoo.org> 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
> 
> 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.
> 
> 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?
> > 
> > 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.

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.
> 
> [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.

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
> =cat/pkg-ver.

GLEP 55 does not change the EAPI process from a maintainer perspective,
except that it replaces "set EAPI=X 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.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]