1 |
On Mon, 14 Jul 2008 02:22:35 +0100 |
2 |
Ciaran McCreesh <ciaran.mccreesh@××××××××××.com> wrote: |
3 |
|
4 |
> On Mon, 14 Jul 2008 03:13:44 +0200 |
5 |
> Jeroen Roovers <jer@g.o> wrote: |
6 |
> > On Mon, 14 Jul 2008 00:43:06 +0100 |
7 |
> > Ciaran McCreesh <ciaran.mccreesh@××××××××××.com> wrote: |
8 |
> > > People are already doing those other things, and doing them badly, |
9 |
> > > because there's currently no other option. This isn't some |
10 |
> > > hypothetical future requirement. |
11 |
> > |
12 |
> > When you wrote "doing them badly", did you mean to imply doing |
13 |
> > something else than GLEP 55, or were you just slagging off whoever |
14 |
> > implemented eblits in sys-libs/glibc? |
15 |
> |
16 |
> As much as you like to try to find some way of taking offence at |
17 |
> everything I write, no, there's no slagging off in there. |
18 |
|
19 |
I'm sorry to say this, but I actually do take offence at most things you |
20 |
write. |
21 |
|
22 |
> As you know fine well, implementing what clearly should be |
23 |
|
24 |
Please stop assuming people know everything you know and/or that people |
25 |
should know everything you know. This is a public forum where you should |
26 |
undertake to explain yourself fully instead of referring vaguely to an |
27 |
unknown set of morals and then suggesting another party should address |
28 |
whatever conflicts with that. It is a particularly subtle variant of |
29 |
the classic straw man that you regularly wield, and it is one of those |
30 |
things that often makes me take offence at what you write. |
31 |
|
32 |
> package manager provided functionality as hacks in an ebuild is never |
33 |
> going to give a nice, elegant solution. However, if package manager |
34 |
> functionality isn't available and can't become available quickly, it |
35 |
> might be the only solution until such functionality can come along. |
36 |
|
37 |
So it's not "doing them badly", it's currently the only solution and |
38 |
you haven't provided any arguments against this only solution as yet. |
39 |
|
40 |
> And making sure such functionality can come along is at least partly |
41 |
> the Council's responsibility. |
42 |
|
43 |
So that's one count of "nice, elegant", and apparently that is what you |
44 |
feel opposes "doing them badly"? |
45 |
|
46 |
> > In other words perhaps, is it your opinion that GLEP 55 needs to be |
47 |
> > implemented because sys-libs/glibc requires an immediate rewrite? |
48 |
> > Are there any bug reports that would be good examples of why this |
49 |
> > new implementation is warranted? |
50 |
> |
51 |
> GLEP 55 wouldn't even allow an immediate rewrite of glibc because new |
52 |
> EAPIs can't easily be used on system packages. |
53 |
|
54 |
Oh. You just shot down your only real world example (eblit versus GLEP |
55 |
55). If you have any more, I'd happily have a look at them, as would |
56 |
anyone else worrying about the consequences of having GLEP 55 |
57 |
implemented. |
58 |
|
59 |
> So no. Instead, GLEP 55 would allow a future EAPI to introduce a |
60 |
> proper per-package eclass-like solution at the package manager level, |
61 |
> which could then over time be phased into glibc, and over less time |
62 |
> be phased into other packages that would make use of it. That's the |
63 |
> nice thing about the GLEP -- it allows the phased introduction of a |
64 |
> larger class improvements without major upheaval. |
65 |
|
66 |
[Class _of_ improvements, I guess.] |
67 |
|
68 |
Please provide an example of what that process would look like. You've |
69 |
always been good at these "we have ebuild 1, then ebuild 2 comes along, |
70 |
depending on ebuild 3 [...]" games, so please explain what we'd end |
71 |
up with in a hypothetical GLEP 55 compliant gentoo-x86/sys-libs/glibc, |
72 |
with "build files" (formerly ebuilds) getting added, removed, |
73 |
keyworded, package.masked and so on. |
74 |
|
75 |
What _I_ envision now is a motley crew of EAPI suffixed "build files" |
76 |
processing through gentoo-x86/sys-libs/glibc over time. Surely it |
77 |
would look a right mess every time you needed to go into that |
78 |
directory (particularly not in a role as any package manager's user or |
79 |
developer, but as a "build file" developer browsing through those |
80 |
files). |
81 |
|
82 |
What GLEP 55 fails to address right now is the very development process |
83 |
it is seemingly supposed to alleviate. It addresses the issue of EAPI |
84 |
implementation from the viewpoint of the package manager's developer, |
85 |
but it doesn't begin to address the viewpoint of the package |
86 |
maintainer or architecture developer at all. It looks to me like a lot |
87 |
of problems are moved out of the package manager(s) and into this |
88 |
already huge tree of files, with different EAPI-suffixed files |
89 |
addressing different problems, and that indicate be a non-trivial |
90 |
increase in the number of files in the tree - files which would |
91 |
address the equal purpose of installing exactly one =cat/pkg-ver. |
92 |
|
93 |
In other words, disregarding its other real world deficiencies like an |
94 |
immediate goal, GLEP 55 fails to describe a keywording policy for |
95 |
architecture developers and it fails to describe a "build file" |
96 |
addition (bump) policy for package maintainers. |
97 |
|
98 |
I grant you that on the surface it really does look nice and elegant. |
99 |
|
100 |
|
101 |
JeR |
102 |
-- |
103 |
gentoo-dev@l.g.o mailing list |