1 |
On Mon, 14 Jul 2008 05:32:58 +0200 |
2 |
Jeroen Roovers <jer@g.o> wrote: |
3 |
> I'm sorry to say this, but I actually do take offence at most things |
4 |
> you write. |
5 |
|
6 |
Perhaps you should consider what that indicates about yourself, rather |
7 |
than about me. |
8 |
|
9 |
> > As you know fine well, implementing what clearly should be |
10 |
> |
11 |
> Please stop assuming people know everything you know and/or that |
12 |
> people should know everything you know. This is a public forum where |
13 |
> you should undertake to explain yourself fully instead of referring |
14 |
> vaguely to an unknown set of morals and then suggesting another party |
15 |
> should address whatever conflicts with that. It is a particularly |
16 |
> subtle variant of the classic straw man that you regularly wield, and |
17 |
> it is one of those things that often makes me take offence at what |
18 |
> you write. |
19 |
|
20 |
All I'm assuming is that people have read and understood the GLEP, and |
21 |
in any places where they don't understand, they ask. Is that assuming |
22 |
too much? |
23 |
|
24 |
> > package manager provided functionality as hacks in an ebuild is |
25 |
> > never going to give a nice, elegant solution. However, if package |
26 |
> > manager functionality isn't available and can't become available |
27 |
> > quickly, it might be the only solution until such functionality can |
28 |
> > come along. |
29 |
> |
30 |
> So it's not "doing them badly", it's currently the only solution and |
31 |
> you haven't provided any arguments against this only solution as yet. |
32 |
|
33 |
No, it is doing it badly. A square wheel is bad, even if it was |
34 |
necessary because the round one was unattainable. |
35 |
|
36 |
> > > In other words perhaps, is it your opinion that GLEP 55 needs to |
37 |
> > > be implemented because sys-libs/glibc requires an immediate |
38 |
> > > rewrite? Are there any bug reports that would be good examples of |
39 |
> > > why this new implementation is warranted? |
40 |
> > |
41 |
> > GLEP 55 wouldn't even allow an immediate rewrite of glibc because |
42 |
> > new EAPIs can't easily be used on system packages. |
43 |
> |
44 |
> Oh. You just shot down your only real world example (eblit versus GLEP |
45 |
> 55). If you have any more, I'd happily have a look at them, as would |
46 |
> anyone else worrying about the consequences of having GLEP 55 |
47 |
> implemented. |
48 |
|
49 |
Uh. Future versions of glibc? Read what I wrote. |
50 |
|
51 |
> > So no. Instead, GLEP 55 would allow a future EAPI to introduce a |
52 |
> > proper per-package eclass-like solution at the package manager |
53 |
> > level, which could then over time be phased into glibc, and over |
54 |
> > less time be phased into other packages that would make use of it. |
55 |
> > That's the nice thing about the GLEP -- it allows the phased |
56 |
> > introduction of a larger class improvements without major upheaval. |
57 |
> |
58 |
> [Class _of_ improvements, I guess.] |
59 |
> |
60 |
> Please provide an example of what that process would look like. You've |
61 |
> always been good at these "we have ebuild 1, then ebuild 2 comes |
62 |
> along, depending on ebuild 3 [...]" games, so please explain what |
63 |
> we'd end up with in a hypothetical GLEP 55 compliant |
64 |
> gentoo-x86/sys-libs/glibc, with "build files" (formerly ebuilds) |
65 |
> getting added, removed, keyworded, package.masked and so on. |
66 |
|
67 |
New, experimental glibc versions that aren't expected to go stable |
68 |
quickly use the new EAPI. Existing versions and any "will need to go |
69 |
stable soon" bumps stay using the old EAPI. After the next release |
70 |
(which is *only* an issue for dependencies of the package manager) |
71 |
all new glibc versions use the new EAPI. |
72 |
|
73 |
> What _I_ envision now is a motley crew of EAPI suffixed "build files" |
74 |
> processing through gentoo-x86/sys-libs/glibc over time. Surely it |
75 |
> would look a right mess every time you needed to go into that |
76 |
> directory (particularly not in a role as any package manager's user or |
77 |
> developer, but as a "build file" developer browsing through those |
78 |
> files). |
79 |
|
80 |
How does: |
81 |
|
82 |
$ ls |
83 |
ChangeLog glibc-2.3.6-r4.ebuild glibc-2.5.1.ebuild |
84 |
Manifest glibc-2.3.6-r5.ebuild glibc-2.6.1.ebuild |
85 |
files glibc-2.4-r4.ebuild glibc-2.6.ebuild |
86 |
glibc-2.2.5-r10.ebuild glibc-2.5-r2.ebuild glibc-2.7-r2.ebuild |
87 |
glibc-2.3.2-r12.ebuild glibc-2.5-r3.ebuild |
88 |
glibc-2.8_p20080602.ebuild-2 |
89 |
glibc-2.3.5-r3.ebuild glibc-2.5-r4.ebuild metadata.xml |
90 |
|
91 |
look any worse than what's there now? |
92 |
|
93 |
> What GLEP 55 fails to address right now is the very development |
94 |
> process it is seemingly supposed to alleviate. It addresses the issue |
95 |
> of EAPI implementation from the viewpoint of the package manager's |
96 |
> developer, but it doesn't begin to address the viewpoint of the |
97 |
> package maintainer or architecture developer at all. It looks to me |
98 |
> like a lot of problems are moved out of the package manager(s) and |
99 |
> into this already huge tree of files, with different EAPI-suffixed |
100 |
> files addressing different problems, and that indicate be a |
101 |
> non-trivial increase in the number of files in the tree - files which |
102 |
> would address the equal purpose of installing exactly one |
103 |
> =cat/pkg-ver. |
104 |
|
105 |
GLEP 55 does not change the EAPI process from a maintainer perspective, |
106 |
except that it replaces "set EAPI=X in the ebuild" with "use .ebuild-X". |
107 |
|
108 |
> In other words, disregarding its other real world deficiencies like an |
109 |
> immediate goal, GLEP 55 fails to describe a keywording policy for |
110 |
> architecture developers and it fails to describe a "build file" |
111 |
> addition (bump) policy for package maintainers. |
112 |
|
113 |
There *is* no change there. |
114 |
|
115 |
-- |
116 |
Ciaran McCreesh |