Re: [gentoo-council] Re: [gentoo-pms] kdebuild-1 conditionales

[Mike Frysinger]

On Monday 14 December 2009 10:14:37 Ciaran McCreesh wrote:
> On Sun, 13 Dec 2009 21:31:11 -0500 Mike Frysinger wrote:
> > > Uh. No. As per the Council's request, we turned off kdebuild-1 for
> > > the approved generated versions of the spec, and we made it
> > > possible to show kdebuild-1-specific things in a different colour.
> >
> > i'm talking about when this crap was added originally, not any recent
> > conversations
>
> That was when it was added.

and ?  it should have been deleted then and it should be deleted now.

> > > So you're telling users who did what the Gentoo KDE project told
> > > them to do that you don't care about them enough to handle the
> > > removal in a carefully controlled manner?
> >
> > no one here said you had to change your PM.  i could care less about
> > your PM. feel free to keep that crap in your PM forever ...
>
> Keeping it around without a specification is a bad idea. And no, the
> plan is not to keep it anywhere forever. The plan is to keep it around
> until we can ensure that users aren't going to be affected by the
> removal.

which is irrelevant to the PMS.  fact is, only your PM supports it and no one 
is telling you what to do with your PM.  correctly removing it from PMS wont 
affect any user whatsoever.  absolutely no users would be affected by cleaning 
up the PMS git tree.

> > it is after all your own fault.
>
> For helping the Gentoo KDE team out? I'll bear that in mind next time
> Gentoo developers want help with something.

what wonderful slant you have.  you didnt work with the KDE team out of the 
kindness of your heart, you worked with developers who were on your side and 
controlled significant stack of Gentoo ebuilds that users relied on.  their 
only option to use the bleeding edge was to switch to your PM.

as for "it's what the official KDE docs said", that too is complete bs.  there 
are teams with more important ebuilds that have instructions that only work 
with portage.  if anyone tried to add these to the PMS, you'll fully bitch and 
moan and block it from ever making it into the PMS.  some of these rely on 
portage behavior with the environment and some of these rely on behavior 
portage has had for years (and before the PMS).

> > it's actually kind of sad how you can sit there and block any PMS
> > additions that have been used in the tree for years because you didnt
> > feel like implementing it in your PM
>
> Uh. Riiiiight. I'm just drowning in bug reports from users who're using
> ebuilds that break with Paludis because we haven't implemented things
> that've been used in the tree for years. Perhaps you'd care to back up
> your mud-slinging with some examples.

stop with your misdirection bullshit.  you know plenty of examples.  then 
again, your style is to keep whining that you arent aware of anything until 
someone explicitly mentions them, so there's prep*, FEATURES, and 
CBUILD/CTARGET in econf to mention a few.

> > yet crap that was explicitly never official or in used in the tree
> > you feel you have a right to keep in the PMS.
>
> It was added at the request of the Gentoo KDE team. It wasn't added
> because I wanted it; it was added because Gentoo developers asked for
> it. I realise you like to pretend that the people who asked for it
> never existed, but the fact is they did, and it would be irresponsible
> of Gentoo to make users suffer because of internal politicking.

great !  so when are you going to add these features that have existed for 
years in portage to the PMS ?  your logic is complete crap.

> > it doesnt belong there, it never has, so delete it/branch it already.
>
> You still haven't explained why it's better to delete it now than to do
> a controlled removal that won't affect users.

and you have yet to show how your PM behavior is relevant one bit to the PMS 
here.  removing unofficial crap from the PMS has no bearing whatsoever on 
ebuilds that require unofficial PMs.  keep the crap in your PM forever for all 
i care.
-mike