1 |
On Fri, Dec 11, 2009 at 07:53:32PM +0000, Ciaran McCreesh wrote: |
2 |
> On Fri, 11 Dec 2009 11:42:41 -0800 |
3 |
> Brian Harring <ferringb@×××××.com> wrote: |
4 |
> > Bluntly, you would be pissed if you got stuck having long term |
5 |
> > support for an experimental eapi I split w/out consult- why do you |
6 |
> > think that the reverse wouldn't hold? |
7 |
> |
8 |
> No, if a large project such as, say, the Gentoo KDE project, had asked |
9 |
> you for support for a well documented EAPI and you had provided it, I |
10 |
> would have also implemented that EAPI in Paludis. |
11 |
> |
12 |
> kdebuild-1 was not done without consultation. It was the result of a |
13 |
> considerable amount of work from an official Gentoo project, and it was |
14 |
> a well defined, published standard. It was in no way an experiment. |
15 |
|
16 |
And if gnome decides they want their own format, is PMS/eapi stuck w/ |
17 |
the bill? |
18 |
|
19 |
|
20 |
> > Regardless, if you didn't plan for phasing out an experimental eapi, |
21 |
> > it's not the mainstream eapi's problem- it's your mess to clean up. |
22 |
> |
23 |
> kdebuild-1 was not experimental. |
24 |
|
25 |
It wasn't official, thus *you* can view it was non-experimental w/in |
26 |
the paludis realm, but it's experimental to gentoo as a whole- the |
27 |
primary pkg manager, the official manager specifically, didn't even |
28 |
support it. |
29 |
|
30 |
It was experimental. |
31 |
|
32 |
|
33 |
> > What I find pointless about this discussion is this notion that |
34 |
> > because you jammed kdebuild into the official eapi doc, the pms team |
35 |
> > in it's current incarnation is responsible for keeping kdebuild |
36 |
> > around and cleaning up that mess. |
37 |
> |
38 |
> No no no. Because the Gentoo PMS project, at the request of the Gentoo |
39 |
> KDE project, included support for one of their published EAPIs, the |
40 |
> Gentoo PMS project would be irresponsible to just remove it without |
41 |
> ensuring that it won't affect users. |
42 |
|
43 |
PMS was irresponsible for allowing it into the official eapis in the |
44 |
first place. If KDE intended it to be supported long term (which I |
45 |
strongly doubt, it was an overlay of unstable ebuilds after all), then |
46 |
they too were irresponsible. |
47 |
|
48 |
Frankly, it's irresponsible of PMS right now to leave it in the docs- |
49 |
I've seen too much confusion from users about what is supported/not |
50 |
because of it. That *is* irresponsible to leave in place. |
51 |
|
52 |
|
53 |
> > 2) write a converter. As said, since it's only *rm phases you really |
54 |
> > have to care about for allowing it to be removed by other managers, |
55 |
> > this isn't incredibly hard- further, full metadata rewrite is |
56 |
> > probably possible w/ eapi2 bits. |
57 |
> |
58 |
> Writing a converter is more work than a simple phased removal. |
59 |
|
60 |
I didn't imply a full format converter. I implied a converter that |
61 |
tweak it enough the thing could be uninstalled by *any* package |
62 |
manager supporting eapi2. I'd expect that would cover a significant |
63 |
majority of any remaining (if even there are remaining) installed |
64 |
pkgs. |
65 |
|
66 |
|
67 |
> > That solves it technically, rather then just ignoring it and |
68 |
> > pretending we won't have this exact discussion a year later w/ the |
69 |
> > same claims as to why it can't be removed. |
70 |
> |
71 |
> A year later, we can easily have had kdebuild-1 removed in a |
72 |
> responsible manner. |
73 |
|
74 |
You have zero stats now to backup that statement- basically your |
75 |
prediction of when it'll be fine to remove it is based on opinion. |
76 |
|
77 |
Via the same rules, my opinion is that it's fine to remove it now. 1 |
78 |
-1 = 0. |
79 |
|
80 |
Back this up w/ stats please in the future. |
81 |
|
82 |
|
83 |
> > Additional thing- note the compromise I mentioned, adding into PMS |
84 |
> > urls directing users where to go for experimental format information, |
85 |
> > or to get at old/dead official eapis. If they can't catch a |
86 |
> > paragraph upfront telling them where to look, it's their problem. |
87 |
> |
88 |
> More work than just doing it properly. |
89 |
|
90 |
Depends on your definition of 'properly'. I presume what you mean is |
91 |
that it requires you to maintain a kdebuild pms pdf somewhere- more |
92 |
work for you. |
93 |
|
94 |
My stance, it's more work for the rest of us coding around the ifdef |
95 |
mess (most recent bitchfest from it was grobian doing the prefix |
96 |
patch). |
97 |
|
98 |
Properly to me means using the dvcs's capabilities, and making it |
99 |
easier for folks to do *official* eapi work w/out having to maintain |
100 |
dross someone shoved into it. Move the effort of maintaining kdebuild |
101 |
bits to those who are responsible for it, effectively. |
102 |
|
103 |
|
104 |
> > Finally, and I admit this is a bit barbed- any user who install this |
105 |
> > eapi should've known it was experimental and that they could get |
106 |
> > support for it for paludis only. If the user thought it was someday |
107 |
> > going to become an official eapi, that's the user/managers problem, |
108 |
> > not ours. |
109 |
> |
110 |
> kdebuild-1 was not experimental. It was an official Gentoo KDE project |
111 |
> EAPI. |
112 |
|
113 |
Goodie on them. Note that it's "official gentoo kde project", not |
114 |
"official eapi". |
115 |
|
116 |
Then they can maintain it w/ paludis, rather then the current PMS |
117 |
incarnation being stuck with it. |
118 |
|
119 |
|
120 |
> > More importantly, pms's responsibility/purpose for gentoo is |
121 |
> > presenting users with documentation on the *official* eapis- forcing |
122 |
> > kdebuild bits into that doc misleads users into thinking kdebuild is |
123 |
> > official, thus supported. User confusion there is, and has been, |
124 |
> > rather annoying. |
125 |
> |
126 |
> And at the time, the Gentoo KDE project considered kdebuild-1 to be an |
127 |
> official EAPI. |
128 |
|
129 |
And they have zero ability to define what is an official EAPI. |
130 |
Misunderstanding reality bluntly, is their problem. |
131 |
|
132 |
As I said, are we on the hook if gnome decides they want their own |
133 |
format? No. |
134 |
|
135 |
Further, note prefix- that is a far more widespread deployment of an |
136 |
experimental eapi, longer lived (and still living even). PMS ain't on |
137 |
the hook for their experimental work- they went and got it approved as |
138 |
an EAPI, for the new EAPI pms is *now* on the hook. |
139 |
|
140 |
That's the proper way to have an official eapi. Someone |
141 |
misunderstanding reality, or misrepresenting reality and claiming an |
142 |
experimental eapi is 'official' is not our problem, and not even |
143 |
remotely something we should be bound by. |
144 |
|
145 |
I'll note finally that when gentoo-kde went and had their brief liason |
146 |
w/ kdebuild, the issues of long term support of the format were known- |
147 |
further it was made abundantly clear to them that from portage/pkgcore |
148 |
standpoint it was an experimental eapi and there wasn't a gurantee |
149 |
we'd ever implement it (in my case I'm reasonably sure the phrase |
150 |
"when hell freezes over" was uttered more then once). |
151 |
|
152 |
I'm sorry if this causes folks any issue, but both paludis and |
153 |
gentoo-kde knew what they were getting into when they went down this |
154 |
path. Frankly I really don't think any users are going to be affected |
155 |
by punting this out of PMS- paludis still carries the support (and is |
156 |
the users only option from day one for removing those packages) |
157 |
|
158 |
You're arguing this must remain in PMS so that folks implementing |
159 |
managers can see it. Nobody is going to implement kdebuild- at best I |
160 |
may write a converter just to bail those users out, but that's likely |
161 |
the extent of effort people will extend on cleaning it up. |
162 |
|
163 |
Beyond that, a compromise was offered so that experimental eapis, and |
164 |
dead/old eapis can be retired from the document. |
165 |
|
166 |
Gentoo doesn't really even need to do that- that's just an attempt to |
167 |
be nice and compromise. If that's not good enough, frankly, tough |
168 |
cookies from where I'm sitting. |
169 |
|
170 |
~harring |