1 |
On Monday 14 December 2009 10:14:37 Ciaran McCreesh wrote: |
2 |
> On Sun, 13 Dec 2009 21:31:11 -0500 Mike Frysinger wrote: |
3 |
> > > Uh. No. As per the Council's request, we turned off kdebuild-1 for |
4 |
> > > the approved generated versions of the spec, and we made it |
5 |
> > > possible to show kdebuild-1-specific things in a different colour. |
6 |
> > |
7 |
> > i'm talking about when this crap was added originally, not any recent |
8 |
> > conversations |
9 |
> |
10 |
> That was when it was added. |
11 |
|
12 |
and ? it should have been deleted then and it should be deleted now. |
13 |
|
14 |
> > > So you're telling users who did what the Gentoo KDE project told |
15 |
> > > them to do that you don't care about them enough to handle the |
16 |
> > > removal in a carefully controlled manner? |
17 |
> > |
18 |
> > no one here said you had to change your PM. i could care less about |
19 |
> > your PM. feel free to keep that crap in your PM forever ... |
20 |
> |
21 |
> Keeping it around without a specification is a bad idea. And no, the |
22 |
> plan is not to keep it anywhere forever. The plan is to keep it around |
23 |
> until we can ensure that users aren't going to be affected by the |
24 |
> removal. |
25 |
|
26 |
which is irrelevant to the PMS. fact is, only your PM supports it and no one |
27 |
is telling you what to do with your PM. correctly removing it from PMS wont |
28 |
affect any user whatsoever. absolutely no users would be affected by cleaning |
29 |
up the PMS git tree. |
30 |
|
31 |
> > it is after all your own fault. |
32 |
> |
33 |
> For helping the Gentoo KDE team out? I'll bear that in mind next time |
34 |
> Gentoo developers want help with something. |
35 |
|
36 |
what wonderful slant you have. you didnt work with the KDE team out of the |
37 |
kindness of your heart, you worked with developers who were on your side and |
38 |
controlled significant stack of Gentoo ebuilds that users relied on. their |
39 |
only option to use the bleeding edge was to switch to your PM. |
40 |
|
41 |
as for "it's what the official KDE docs said", that too is complete bs. there |
42 |
are teams with more important ebuilds that have instructions that only work |
43 |
with portage. if anyone tried to add these to the PMS, you'll fully bitch and |
44 |
moan and block it from ever making it into the PMS. some of these rely on |
45 |
portage behavior with the environment and some of these rely on behavior |
46 |
portage has had for years (and before the PMS). |
47 |
|
48 |
> > it's actually kind of sad how you can sit there and block any PMS |
49 |
> > additions that have been used in the tree for years because you didnt |
50 |
> > feel like implementing it in your PM |
51 |
> |
52 |
> Uh. Riiiiight. I'm just drowning in bug reports from users who're using |
53 |
> ebuilds that break with Paludis because we haven't implemented things |
54 |
> that've been used in the tree for years. Perhaps you'd care to back up |
55 |
> your mud-slinging with some examples. |
56 |
|
57 |
stop with your misdirection bullshit. you know plenty of examples. then |
58 |
again, your style is to keep whining that you arent aware of anything until |
59 |
someone explicitly mentions them, so there's prep*, FEATURES, and |
60 |
CBUILD/CTARGET in econf to mention a few. |
61 |
|
62 |
> > yet crap that was explicitly never official or in used in the tree |
63 |
> > you feel you have a right to keep in the PMS. |
64 |
> |
65 |
> It was added at the request of the Gentoo KDE team. It wasn't added |
66 |
> because I wanted it; it was added because Gentoo developers asked for |
67 |
> it. I realise you like to pretend that the people who asked for it |
68 |
> never existed, but the fact is they did, and it would be irresponsible |
69 |
> of Gentoo to make users suffer because of internal politicking. |
70 |
|
71 |
great ! so when are you going to add these features that have existed for |
72 |
years in portage to the PMS ? your logic is complete crap. |
73 |
|
74 |
> > it doesnt belong there, it never has, so delete it/branch it already. |
75 |
> |
76 |
> You still haven't explained why it's better to delete it now than to do |
77 |
> a controlled removal that won't affect users. |
78 |
|
79 |
and you have yet to show how your PM behavior is relevant one bit to the PMS |
80 |
here. removing unofficial crap from the PMS has no bearing whatsoever on |
81 |
ebuilds that require unofficial PMs. keep the crap in your PM forever for all |
82 |
i care. |
83 |
-mike |