Re: [gentoo-pms] kdebuild-1 conditionales

[Brian Harring]

On Fri, Dec 11, 2009 at 07:53:32PM +0000, Ciaran McCreesh wrote:
> On Fri, 11 Dec 2009 11:42:41 -0800
> Brian Harring <ferringb@×××××.com> wrote:
> > Bluntly, you would be pissed if you got stuck having long term
> > support for an experimental eapi I split w/out consult- why do you
> > think that the reverse wouldn't hold?
>
> No, if a large project such as, say, the Gentoo KDE project, had asked
> you for support for a well documented EAPI and you had provided it, I
> would have also implemented that EAPI in Paludis.
>
> kdebuild-1 was not done without consultation. It was the result of a
> considerable amount of work from an official Gentoo project, and it was
> a well defined, published standard. It was in no way an experiment.

And if gnome decides they want their own format, is PMS/eapi stuck w/ 
the bill?


> > Regardless, if you didn't plan for phasing out an experimental eapi,
> > it's not the mainstream eapi's problem- it's your mess to clean up.
>
> kdebuild-1 was not experimental.

It wasn't official, thus *you* can view it was non-experimental w/in 
the paludis realm, but it's experimental to gentoo as a whole- the 
primary pkg manager, the official manager specifically, didn't even 
support it.

It was experimental.


> > What I find pointless about this discussion is this notion that
> > because you jammed kdebuild into the official eapi doc, the pms team
> > in it's current incarnation is responsible for keeping kdebuild
> > around and cleaning up that mess.
>
> No no no. Because the Gentoo PMS project, at the request of the Gentoo
> KDE project, included support for one of their published EAPIs, the
> Gentoo PMS project would be irresponsible to just remove it without
> ensuring that it won't affect users.

PMS was irresponsible for allowing it into the official eapis in the 
first place.  If KDE intended it to be supported long term (which I 
strongly doubt, it was an overlay of unstable ebuilds after all), then 
they too were irresponsible.

Frankly, it's irresponsible of PMS right now to leave it in the docs- 
I've seen too much confusion from users about what is supported/not 
because of it.  That *is* irresponsible to leave in place.


> > 2) write a converter.  As said, since it's only *rm phases you really
> > have to care about for allowing it to be removed by other managers,
> > this isn't incredibly hard- further, full metadata rewrite is
> > probably possible w/ eapi2 bits.
>
> Writing a converter is more work than a simple phased removal.

I didn't imply a full format converter.  I implied a converter that 
tweak it enough the thing could be uninstalled by *any* package 
manager supporting eapi2.  I'd expect that would cover a significant 
majority of any remaining (if even there are remaining) installed 
pkgs.


> > That solves it technically, rather then just ignoring it and
> > pretending we won't have this exact discussion a year later w/ the
> > same claims as to why it can't be removed.
>
> A year later, we can easily have had kdebuild-1 removed in a
> responsible manner.

You have zero stats now to backup that statement- basically your 
prediction of when it'll be fine to remove it is based on opinion.

Via the same rules, my opinion is that it's fine to remove it now.  1 
-1 = 0.

Back this up w/ stats please in the future.


> > Additional thing- note the compromise I mentioned, adding into PMS
> > urls directing users where to go for experimental format information,
> > or to get at old/dead official eapis.  If they can't catch a
> > paragraph upfront telling them where to look, it's their problem.
>
> More work than just doing it properly.

Depends on your definition of 'properly'.  I presume what you mean is 
that it requires you to maintain a kdebuild pms pdf somewhere- more 
work for you.

My stance, it's more work for the rest of us coding around the ifdef 
mess (most recent bitchfest from it was grobian doing the prefix 
patch).

Properly to me means using the dvcs's capabilities, and making it 
easier for folks to do *official* eapi work w/out having to maintain 
dross someone shoved into it.  Move the effort of maintaining kdebuild 
bits to those who are responsible for it, effectively.


> > Finally, and I admit this is a bit barbed- any user who install this
> > eapi should've known it was experimental and that they could get
> > support for it for paludis only.  If the user thought it was someday
> > going to become an official eapi, that's the user/managers problem,
> > not ours.
>
> kdebuild-1 was not experimental. It was an official Gentoo KDE project
> EAPI.

Goodie on them.  Note that it's "official gentoo kde project", not 
"official eapi".

Then they can maintain it w/ paludis, rather then the current PMS 
incarnation being stuck with it.


> > More importantly, pms's responsibility/purpose for gentoo is
> > presenting users with documentation on the *official* eapis- forcing
> > kdebuild bits into that doc misleads users into thinking kdebuild is
> > official, thus supported.  User confusion there is, and has been,
> > rather annoying.
>
> And at the time, the Gentoo KDE project considered kdebuild-1 to be an
> official EAPI.

And they have zero ability to define what is an official EAPI.  
Misunderstanding reality bluntly, is their problem.

As I said, are we on the hook if gnome decides they want their own 
format?  No.

Further, note prefix- that is a far more widespread deployment of an 
experimental eapi, longer lived (and still living even).  PMS ain't on 
the hook for their experimental work- they went and got it approved as 
an EAPI, for the new EAPI pms is *now* on the hook.

That's the proper way to have an official eapi.  Someone 
misunderstanding reality, or misrepresenting reality and claiming an 
experimental eapi is 'official' is not our problem, and not even 
remotely something we should be bound by.

I'll note finally that when gentoo-kde went and had their brief liason 
w/ kdebuild, the issues of long term support of the format were known- 
further it was made abundantly clear to them that from portage/pkgcore 
standpoint it was an experimental eapi and there wasn't a gurantee 
we'd ever implement it (in my case I'm reasonably sure the phrase 
"when hell freezes over" was uttered more then once).

I'm sorry if this causes folks any issue, but both paludis and 
gentoo-kde knew what they were getting into when they went down this 
path.  Frankly I really don't think any users are going to be affected 
by punting this out of PMS- paludis still carries the support (and is 
the users only option from day one for removing those packages)

You're arguing this must remain in PMS so that folks implementing 
managers can see it.  Nobody is going to implement kdebuild- at best I 
may write a converter just to bail those users out, but that's likely 
the extent of effort people will extend on cleaning it up.

Beyond that, a compromise was offered so that experimental eapis, and 
dead/old eapis can be retired from the document.

Gentoo doesn't really even need to do that- that's just an attempt to 
be nice and compromise.  If that's not good enough, frankly, tough 
cookies from where I'm sitting.

~harring