1 |
On Fri, Dec 11, 2009 at 06:27:39PM +0000, Ciaran McCreesh wrote: |
2 |
> On Fri, 11 Dec 2009 19:14:39 +0100 |
3 |
> The impact is that those of us using PMS for developing a package |
4 |
> manager have to go back and change it. |
5 |
|
6 |
Not really. |
7 |
|
8 |
Paludis is, and was, the only one that supported kdebuild. Meaning |
9 |
any user of kdebuild is *already* bound to paludis- again, bluntly, |
10 |
this is a paludis specific mess. If I ever write anything kdebuild |
11 |
specific, it would be a converter- this is something the paludis folk |
12 |
should be doing if they're really concerned about users still running |
13 |
kdebuild (since you'd just have to focus on *rm phases, it's pretty |
14 |
straightforward). |
15 |
|
16 |
Bluntly, you would be pissed if you got stuck having long term support |
17 |
for an experimental eapi I split w/out consult- why do you think that |
18 |
the reverse wouldn't hold? My point here is that pkgcore won't be |
19 |
implementing kdebuild anytime soon, nor would I expect portage ever to |
20 |
do so. At best, a converter might be written, but that's it- I'm not |
21 |
going to put time into a dead format for a mess that isn't mine, |
22 |
essentially. |
23 |
|
24 |
Regardless, if you didn't plan for phasing out an experimental eapi, |
25 |
it's not the mainstream eapi's problem- it's your mess to clean up. |
26 |
If the user goes and installs something experimental/unsupported, |
27 |
that's their issue- the folks they can yell at are their upstream |
28 |
(the manager in this case, and gentoo kde). |
29 |
|
30 |
If we did as you asked, we would have to document every pre eapi |
31 |
portage has had (at least 8 off the top of my head), the previous |
32 |
iterations of prefix, and realistically, the exherbo format should |
33 |
some user manage to install an exheres-0 build into a gentoo box. |
34 |
This *is* the case- it's applying the same logic you're using for |
35 |
trying to keep kdebuild-1 in. |
36 |
|
37 |
What I find pointless about this discussion is this notion that |
38 |
because you jammed kdebuild into the official eapi doc, the pms team |
39 |
in it's current incarnation is responsible for keeping kdebuild |
40 |
around and cleaning up that mess. |
41 |
|
42 |
|
43 |
The proper cleanup if you really wanted this done is the following: |
44 |
1) add warnings into paludis if kdebuild is detected installed, |
45 |
telling them to upgrade/remove whatever, and/or- |
46 |
2) write a converter. As said, since it's only *rm phases you really |
47 |
have to care about for allowing it to be removed by other managers, |
48 |
this isn't incredibly hard- further, full metadata rewrite is probably |
49 |
possible w/ eapi2 bits. |
50 |
3) send out notifications via paludis lists, channels, whatever- |
51 |
basically since this is paludis specific, use those mediums to contact |
52 |
people and let them know the experiment is dead (they should be |
53 |
listening on those mediums anyways). |
54 |
|
55 |
That solves it technically, rather then just ignoring it and |
56 |
pretending we won't have this exact discussion a year later w/ the |
57 |
same claims as to why it can't be removed. |
58 |
|
59 |
Additional thing- note the compromise I mentioned, adding into PMS |
60 |
urls directing users where to go for experimental format information, |
61 |
or to get at old/dead official eapis. If they can't catch a |
62 |
paragraph upfront telling them where to look, it's their problem. |
63 |
|
64 |
Meanwhile, you can maintain the ifdef'd bits in your own branch- hell, |
65 |
just a copy of the existing pms pdf would suffice since kdebuild is a |
66 |
locked/dead format anyways. |
67 |
|
68 |
Finally, and I admit this is a bit barbed- any user who install this |
69 |
eapi should've known it was experimental and that they could get |
70 |
support for it for paludis only. If the user thought it was someday |
71 |
going to become an official eapi, that's the user/managers problem, |
72 |
not ours. |
73 |
|
74 |
Our problem, and our sole area of responsibility , is the latex |
75 |
obfuscation mess- via git, shifting of maintenance of the kdebuild |
76 |
spec to paludis is easy. |
77 |
|
78 |
More importantly, pms's responsibility/purpose for gentoo is |
79 |
presenting users with documentation on the *official* eapis- forcing |
80 |
kdebuild bits into that doc misleads users into thinking kdebuild is |
81 |
official, thus supported. User confusion there is, and has been, |
82 |
rather annoying. |
83 |
|
84 |
~harring |