1 |
On Mon, 14 Jul 2008 03:13:44 +0200 |
2 |
Jeroen Roovers <jer@g.o> wrote: |
3 |
> On Mon, 14 Jul 2008 00:43:06 +0100 |
4 |
> Ciaran McCreesh <ciaran.mccreesh@××××××××××.com> wrote: |
5 |
> > People are already doing those other things, and doing them badly, |
6 |
> > because there's currently no other option. This isn't some |
7 |
> > hypothetical future requirement. |
8 |
> |
9 |
> When you wrote "doing them badly", did you mean to imply doing |
10 |
> something else than GLEP 55, or were you just slagging off whoever |
11 |
> implemented eblits in sys-libs/glibc? |
12 |
|
13 |
As much as you like to try to find some way of taking offence at |
14 |
everything I write, no, there's no slagging off in there. |
15 |
|
16 |
As you know fine well, implementing what clearly should be package |
17 |
manager provided functionality as hacks in an ebuild is never going to |
18 |
give a nice, elegant solution. However, if package manager |
19 |
functionality isn't available and can't become available quickly, it |
20 |
might be the only solution until such functionality can come along. And |
21 |
making sure such functionality can come along is at least partly the |
22 |
Council's responsibility. |
23 |
|
24 |
> In other words perhaps, is it your opinion that GLEP 55 needs to be |
25 |
> implemented because sys-libs/glibc requires an immediate rewrite? Are |
26 |
> there any bug reports that would be good examples of why this new |
27 |
> implementation is warranted? |
28 |
|
29 |
GLEP 55 wouldn't even allow an immediate rewrite of glibc because new |
30 |
EAPIs can't easily be used on system packages. So no. Instead, GLEP 55 |
31 |
would allow a future EAPI to introduce a proper per-package eclass-like |
32 |
solution at the package manager level, which could then over time be |
33 |
phased into glibc, and over less time be phased into other packages |
34 |
that would make use of it. That's the nice thing about the GLEP -- it |
35 |
allows the phased introduction of a larger class improvements without |
36 |
major upheaval. |
37 |
|
38 |
-- |
39 |
Ciaran McCreesh |