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

[Ciaran McCreesh <ciaran.mccreesh@googlemail.com>]

[-- Attachment #1: Type: text/plain, Size: 5640 bytes --]

On Mon, 14 Dec 2009 12:01:03 -0500
Mike Frysinger <vapier@gentoo.org> wrote:
> > > 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.

Not what the Council said. Your personal opinion wasn't what was voted.

> > 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.

> > > 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.

No, I worked with developers who asked me for help, and I gave them
what they asked for, after insisting that it was done as a public,
documented standard precisely to avoid it by necessity being restricted
to a single package manager. That you don't like a decision made by a
Gentoo project is your problem.

> 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.

> 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.

> > 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.

> 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.

> 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".

> > > 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.

If you want FEATURES to be able to be used reliably by ebuilds, you'll
have to get the Portage people to implement that in a new EAPI first.

If you want prep*, you'll have to ask the Portage people to guarantee
that they'll stop changing what it does so we can spec it in in a new
EAPI. However, since EAPI 4 includes a well defined alternative to
prep* abuse, there's probably no need.

I'll give you an answer for CHOST / CTARGET when you point me to the
bug for it, since I can't find it myself and I can't recall what the
conclusion was.

> > > 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.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]