1 |
On Mon, 14 Dec 2009 12:01:03 -0500 |
2 |
Mike Frysinger <vapier@g.o> wrote: |
3 |
> > > i'm talking about when this crap was added originally, not any |
4 |
> > > recent conversations |
5 |
> > |
6 |
> > That was when it was added. |
7 |
> |
8 |
> and ? it should have been deleted then and it should be deleted now. |
9 |
|
10 |
Not what the Council said. Your personal opinion wasn't what was voted. |
11 |
|
12 |
> > Keeping it around without a specification is a bad idea. And no, the |
13 |
> > plan is not to keep it anywhere forever. The plan is to keep it |
14 |
> > around until we can ensure that users aren't going to be affected |
15 |
> > by the removal. |
16 |
> |
17 |
> which is irrelevant to the PMS. fact is, only your PM supports it |
18 |
> and no one is telling you what to do with your PM. correctly |
19 |
> removing it from PMS wont affect any user whatsoever. absolutely no |
20 |
> users would be affected by cleaning up the PMS git tree. |
21 |
|
22 |
As has already been explained, keeping the spec around is a necessary |
23 |
part of keeping the implementation around. |
24 |
|
25 |
> > > it is after all your own fault. |
26 |
> > |
27 |
> > For helping the Gentoo KDE team out? I'll bear that in mind next |
28 |
> > time Gentoo developers want help with something. |
29 |
> |
30 |
> what wonderful slant you have. you didnt work with the KDE team out |
31 |
> of the kindness of your heart, you worked with developers who were on |
32 |
> your side and controlled significant stack of Gentoo ebuilds that |
33 |
> users relied on. their only option to use the bleeding edge was to |
34 |
> switch to your PM. |
35 |
|
36 |
No, I worked with developers who asked me for help, and I gave them |
37 |
what they asked for, after insisting that it was done as a public, |
38 |
documented standard precisely to avoid it by necessity being restricted |
39 |
to a single package manager. That you don't like a decision made by a |
40 |
Gentoo project is your problem. |
41 |
|
42 |
> as for "it's what the official KDE docs said", that too is complete |
43 |
> bs. there are teams with more important ebuilds that have |
44 |
> instructions that only work with portage. |
45 |
|
46 |
I highly doubt that, since if that were the case we'd be receiving |
47 |
reports from users about it. |
48 |
|
49 |
> if anyone tried to add these to the PMS, you'll fully bitch and moan |
50 |
> and block it from ever making it into the PMS. some of these rely on |
51 |
> portage behavior with the environment and some of these rely on |
52 |
> behavior portage has had for years (and before the PMS). |
53 |
|
54 |
Er, no. If that were the case, users wouldn't be able to use Paludis. |
55 |
|
56 |
> > Uh. Riiiiight. I'm just drowning in bug reports from users who're |
57 |
> > using ebuilds that break with Paludis because we haven't |
58 |
> > implemented things that've been used in the tree for years. Perhaps |
59 |
> > you'd care to back up your mud-slinging with some examples. |
60 |
> |
61 |
> stop with your misdirection bullshit. you know plenty of examples. |
62 |
> then again, your style is to keep whining that you arent aware of |
63 |
> anything until someone explicitly mentions them, so there's prep*, |
64 |
|
65 |
prep* can't go in since what it does has yet to be locked down or |
66 |
guaranteed. We can't spec it as "does something arbitrary", yet that's |
67 |
all prep* is guaranteed to do. And, as you know, EAPI 4 has had |
68 |
features added to it to give you what you were after, except done in a |
69 |
well defined manner. |
70 |
|
71 |
> FEATURES |
72 |
|
73 |
There is no legitimate use for FEATURES in the tree, since something |
74 |
being in FEATURES only indicates that the user asked for it, not that |
75 |
it is enabled. For example, ebuilds that do has userpriv $FEATURES are |
76 |
broken, because userpriv in features does not mean that userpriv has |
77 |
actually been enabled by Portage. |
78 |
|
79 |
> and CBUILD/CTARGET in econf to mention a few. |
80 |
|
81 |
Could you point me to the bug for that one please? I think I can see |
82 |
what PMS might be missing on that one, but I don't recall ever seeing a |
83 |
bug about it, or what the conclusion was. I also can't find the bug by |
84 |
searching for comments containing all of the words "pms ctarget", or |
85 |
"pms cbuild". |
86 |
|
87 |
> > > yet crap that was explicitly never official or in used in the tree |
88 |
> > > you feel you have a right to keep in the PMS. |
89 |
> > |
90 |
> > It was added at the request of the Gentoo KDE team. It wasn't added |
91 |
> > because I wanted it; it was added because Gentoo developers asked |
92 |
> > for it. I realise you like to pretend that the people who asked for |
93 |
> > it never existed, but the fact is they did, and it would be |
94 |
> > irresponsible of Gentoo to make users suffer because of internal |
95 |
> > politicking. |
96 |
> |
97 |
> great ! so when are you going to add these features that have |
98 |
> existed for years in portage to the PMS ? your logic is complete |
99 |
> crap. |
100 |
|
101 |
If you want FEATURES to be able to be used reliably by ebuilds, you'll |
102 |
have to get the Portage people to implement that in a new EAPI first. |
103 |
|
104 |
If you want prep*, you'll have to ask the Portage people to guarantee |
105 |
that they'll stop changing what it does so we can spec it in in a new |
106 |
EAPI. However, since EAPI 4 includes a well defined alternative to |
107 |
prep* abuse, there's probably no need. |
108 |
|
109 |
I'll give you an answer for CHOST / CTARGET when you point me to the |
110 |
bug for it, since I can't find it myself and I can't recall what the |
111 |
conclusion was. |
112 |
|
113 |
> > > it doesnt belong there, it never has, so delete it/branch it |
114 |
> > > already. |
115 |
> > |
116 |
> > You still haven't explained why it's better to delete it now than |
117 |
> > to do a controlled removal that won't affect users. |
118 |
> |
119 |
> and you have yet to show how your PM behavior is relevant one bit to |
120 |
> the PMS here. removing unofficial crap from the PMS has no bearing |
121 |
> whatsoever on ebuilds that require unofficial PMs. keep the crap in |
122 |
> your PM forever for all i care. |
123 |
|
124 |
Uh. See earlier emails in the thread. |
125 |
|
126 |
-- |
127 |
Ciaran McCreesh |