Gentoo Archives: gentoo-dev

From: Alistair Bush <ali_bush@g.o>
To: gentoo-dev@l.g.o, lu_zero@g.o
Subject: Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
Date: Tue, 24 Feb 2009 08:07:08
Message-Id: 49A3AAA1.6080207@gentoo.org
In Reply to: Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009) by Luca Barbato
1 Luca Barbato wrote:
2 > Luca Barbato wrote:
3 >> Ciaran McCreesh wrote:
4 >>> Because your proposal addresses none of the underlying problems which
5 >>> GLEP 55 was created to solve.
6 >
7 > let's get some numbers to have an idea of the dimension of the problem.
8 >
9
10 I just don't think those numbers tell us anything and that should be
11 obvious from anyone who has read GLEP 55[1], we ain't really attempting
12 to solve a problem that exists within the tree currently (well the bash
13 issue does, in a way ). We are trying to solve issues that ware stopping
14 the "tree" moving forward. Lets evaluate GLEP 55 in the problems it is
15 attempting to solve.
16
17 [1]
18 Problem
19
20 The current way of specifying the EAPI in ebuilds is flawed. In order to
21 get the EAPI the package manager needs to source the ebuild, which
22 itself needs the EAPI in the first place. Otherwise it imposes a serious
23 limitation, namely every ebuild, using any of the future EAPIs, will
24 have to be source'able by old package managers and hence there is no way
25 to do any of the following:
26
27 * Change the behaviour of inherit in any way (for example, to
28 extend or change eclass functionality).
29 * Add new global scope functions in any sane way.
30 * Extend versioning rules in an EAPI - for example, addition of
31 the scm suffix - GLEP54 [1].

Replies