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

[Mike Frysinger]

On Monday 14 December 2009 13:21:29 Ciaran McCreesh wrote:
> On Mon, 14 Dec 2009 12:01:03 -0500 Mike Frysinger wrote:
> > > 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.
>
> As has already been explained, keeping the spec around is a necessary
> part of keeping the implementation around.

that is purely your own decision.  having it in PMS has 0 bearing on it.  
kdebuild behavior isnt going to magically change semantics with 
pkg_{pre,post}rm and if it does, it isnt going to because someone changes it 
behind your back.  i'm sure you're more than capable of watching the changes 
going into 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.
>
> I highly doubt that, since if that were the case we'd be receiving
> reports from users about it.

i guess i'm not a user and my multislot bug doesnt exist.  and my 
CBUILD/CTARGET reports were discarded.  prepstrip i dont think i bothered 
pushing because of your insistence on ignoring prep* functions.  having broken 
PM (where PM != portage) behavior is what you get then; no sweat off my back.

> > 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).
>
> Er, no. If that were the case, users wouldn't be able to use Paludis.

funny how you use a logic statement in defense of your PM, but then at the 
same exact time use it to block other PMs.  how you manage this constant 
circular logic is beyond me.

> > > 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*,
>
> prep* can't go in since what it does has yet to be locked down or
> guaranteed. We can't spec it as "does something arbitrary", yet that's
> all prep* is guaranteed to do. And, as you know, EAPI 4 has had
> features added to it to give you what you were after, except done in a
> well defined manner.

i dont recall anyone going over a replacement for prepstrip.  the toolchain 
packages have been using this interface for quite a while and rely on it 
working correctly.  current git master doesnt seem to mention anything wrt 
stripping behavior.

> > FEATURES
>
> There is no legitimate use for FEATURES in the tree, since something
> being in FEATURES only indicates that the user asked for it, not that
> it is enabled. For example, ebuilds that do has userpriv $FEATURES are
> broken, because userpriv in features does not mean that userpriv has
> actually been enabled by Portage.

i never said the code/design was clean.  i did however say that we have 
defacto spec that people are relying on and it isnt in PMS and you block it, 
yet specs that was explicitly never approved and never in the tree you had no 
problem adding.

> > and CBUILD/CTARGET in econf to mention a few.
>
> Could you point me to the bug for that one please? I think I can see
> what PMS might be missing on that one, but I don't recall ever seeing a
> bug about it, or what the conclusion was. I also can't find the bug by
> searching for comments containing all of the words "pms ctarget", or
> "pms cbuild".

i told you about it in the very first draft review of PMS and you told me it 
had no business in the PMS and it was a portage-specific feature.  i had to 
bitch and moan to even get mentioned as reserved so it wouldnt be arbitrarily 
hijacked by stupid people.

here's the notes from my initial review i gave you oh-so-long ago and you 
responded on irc at the time (no, i dont have irc logs because i dont log 
anything):
http://dev.gentoo.org/~vapier/PMS-notes

> > > > 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.
>
> Uh. See earlier emails in the thread.

not much point when you have no justification for why it needs to be kept
-mike