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@...> 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/
> > 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
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
> > 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
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
Goodie on them. Note that it's "official gentoo kde project", not
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
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.