1 |
On Fri, 11 Dec 2009 11:42:41 -0800 |
2 |
Brian Harring <ferringb@×××××.com> wrote: |
3 |
> Bluntly, you would be pissed if you got stuck having long term |
4 |
> support for an experimental eapi I split w/out consult- why do you |
5 |
> think that the reverse wouldn't hold? |
6 |
|
7 |
No, if a large project such as, say, the Gentoo KDE project, had asked |
8 |
you for support for a well documented EAPI and you had provided it, I |
9 |
would have also implemented that EAPI in Paludis. |
10 |
|
11 |
kdebuild-1 was not done without consultation. It was the result of a |
12 |
considerable amount of work from an official Gentoo project, and it was |
13 |
a well defined, published standard. It was in no way an experiment. |
14 |
|
15 |
> Regardless, if you didn't plan for phasing out an experimental eapi, |
16 |
> it's not the mainstream eapi's problem- it's your mess to clean up. |
17 |
|
18 |
kdebuild-1 was not experimental. |
19 |
|
20 |
> If we did as you asked, we would have to document every pre eapi |
21 |
> portage has had (at least 8 off the top of my head), the previous |
22 |
> iterations of prefix, and realistically, the exherbo format should |
23 |
> some user manage to install an exheres-0 build into a gentoo box. |
24 |
> This *is* the case- it's applying the same logic you're using for |
25 |
> trying to keep kdebuild-1 in. |
26 |
|
27 |
Er, no. None of those have ever been published, documented standards. |
28 |
|
29 |
> What I find pointless about this discussion is this notion that |
30 |
> because you jammed kdebuild into the official eapi doc, the pms team |
31 |
> in it's current incarnation is responsible for keeping kdebuild |
32 |
> around and cleaning up that mess. |
33 |
|
34 |
No no no. Because the Gentoo PMS project, at the request of the Gentoo |
35 |
KDE project, included support for one of their published EAPIs, the |
36 |
Gentoo PMS project would be irresponsible to just remove it without |
37 |
ensuring that it won't affect users. |
38 |
|
39 |
> 2) write a converter. As said, since it's only *rm phases you really |
40 |
> have to care about for allowing it to be removed by other managers, |
41 |
> this isn't incredibly hard- further, full metadata rewrite is |
42 |
> probably possible w/ eapi2 bits. |
43 |
|
44 |
Writing a converter is more work than a simple phased removal. |
45 |
|
46 |
> That solves it technically, rather then just ignoring it and |
47 |
> pretending we won't have this exact discussion a year later w/ the |
48 |
> same claims as to why it can't be removed. |
49 |
|
50 |
A year later, we can easily have had kdebuild-1 removed in a |
51 |
responsible manner. |
52 |
|
53 |
> Additional thing- note the compromise I mentioned, adding into PMS |
54 |
> urls directing users where to go for experimental format information, |
55 |
> or to get at old/dead official eapis. If they can't catch a |
56 |
> paragraph upfront telling them where to look, it's their problem. |
57 |
|
58 |
More work than just doing it properly. |
59 |
|
60 |
> Finally, and I admit this is a bit barbed- any user who install this |
61 |
> eapi should've known it was experimental and that they could get |
62 |
> support for it for paludis only. If the user thought it was someday |
63 |
> going to become an official eapi, that's the user/managers problem, |
64 |
> not ours. |
65 |
|
66 |
kdebuild-1 was not experimental. It was an official Gentoo KDE project |
67 |
EAPI. |
68 |
|
69 |
> More importantly, pms's responsibility/purpose for gentoo is |
70 |
> presenting users with documentation on the *official* eapis- forcing |
71 |
> kdebuild bits into that doc misleads users into thinking kdebuild is |
72 |
> official, thus supported. User confusion there is, and has been, |
73 |
> rather annoying. |
74 |
|
75 |
And at the time, the Gentoo KDE project considered kdebuild-1 to be an |
76 |
official EAPI. |
77 |
|
78 |
-- |
79 |
Ciaran McCreesh |