Gentoo Archives: gentoo-pms

From: Brian Harring <ferringb@×××××.com>
To: Ciaran McCreesh <ciaran.mccreesh@××××××××××.com>
Cc: gentoo-pms@l.g.o
Subject: Re: [gentoo-pms] kdebuild-1 conditionales
Date: Fri, 11 Dec 2009 22:06:35
Message-Id: 20091211203022.GG6529@hrair
In Reply to: Re: [gentoo-pms] kdebuild-1 conditionales by Ciaran McCreesh
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


Subject Author
Re: [gentoo-pms] kdebuild-1 conditionales Ciaran McCreesh <ciaran.mccreesh@××××××××××.com>