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
1 On Fri, Dec 11, 2009 at 07:53:32PM +0000, Ciaran McCreesh wrote:
2 > On Fri, 11 Dec 2009 11:42:41 -0800
3 > Brian Harring <ferringb@×××××.com> wrote:
4 > > Bluntly, you would be pissed if you got stuck having long term
5 > > support for an experimental eapi I split w/out consult- why do you
6 > > think that the reverse wouldn't hold?
7 >
8 > No, if a large project such as, say, the Gentoo KDE project, had asked
9 > you for support for a well documented EAPI and you had provided it, I
10 > would have also implemented that EAPI in Paludis.
11 >
12 > kdebuild-1 was not done without consultation. It was the result of a
13 > considerable amount of work from an official Gentoo project, and it was
14 > a well defined, published standard. It was in no way an experiment.
16 And if gnome decides they want their own format, is PMS/eapi stuck w/
17 the bill?
20 > > Regardless, if you didn't plan for phasing out an experimental eapi,
21 > > it's not the mainstream eapi's problem- it's your mess to clean up.
22 >
23 > kdebuild-1 was not experimental.
25 It wasn't official, thus *you* can view it was non-experimental w/in
26 the paludis realm, but it's experimental to gentoo as a whole- the
27 primary pkg manager, the official manager specifically, didn't even
28 support it.
30 It was experimental.
33 > > What I find pointless about this discussion is this notion that
34 > > because you jammed kdebuild into the official eapi doc, the pms team
35 > > in it's current incarnation is responsible for keeping kdebuild
36 > > around and cleaning up that mess.
37 >
38 > No no no. Because the Gentoo PMS project, at the request of the Gentoo
39 > KDE project, included support for one of their published EAPIs, the
40 > Gentoo PMS project would be irresponsible to just remove it without
41 > ensuring that it won't affect users.
43 PMS was irresponsible for allowing it into the official eapis in the
44 first place. If KDE intended it to be supported long term (which I
45 strongly doubt, it was an overlay of unstable ebuilds after all), then
46 they too were irresponsible.
48 Frankly, it's irresponsible of PMS right now to leave it in the docs-
49 I've seen too much confusion from users about what is supported/not
50 because of it. That *is* irresponsible to leave in place.
53 > > 2) write a converter. As said, since it's only *rm phases you really
54 > > have to care about for allowing it to be removed by other managers,
55 > > this isn't incredibly hard- further, full metadata rewrite is
56 > > probably possible w/ eapi2 bits.
57 >
58 > Writing a converter is more work than a simple phased removal.
60 I didn't imply a full format converter. I implied a converter that
61 tweak it enough the thing could be uninstalled by *any* package
62 manager supporting eapi2. I'd expect that would cover a significant
63 majority of any remaining (if even there are remaining) installed
64 pkgs.
67 > > That solves it technically, rather then just ignoring it and
68 > > pretending we won't have this exact discussion a year later w/ the
69 > > same claims as to why it can't be removed.
70 >
71 > A year later, we can easily have had kdebuild-1 removed in a
72 > responsible manner.
74 You have zero stats now to backup that statement- basically your
75 prediction of when it'll be fine to remove it is based on opinion.
77 Via the same rules, my opinion is that it's fine to remove it now. 1
78 -1 = 0.
80 Back this up w/ stats please in the future.
83 > > Additional thing- note the compromise I mentioned, adding into PMS
84 > > urls directing users where to go for experimental format information,
85 > > or to get at old/dead official eapis. If they can't catch a
86 > > paragraph upfront telling them where to look, it's their problem.
87 >
88 > More work than just doing it properly.
90 Depends on your definition of 'properly'. I presume what you mean is
91 that it requires you to maintain a kdebuild pms pdf somewhere- more
92 work for you.
94 My stance, it's more work for the rest of us coding around the ifdef
95 mess (most recent bitchfest from it was grobian doing the prefix
96 patch).
98 Properly to me means using the dvcs's capabilities, and making it
99 easier for folks to do *official* eapi work w/out having to maintain
100 dross someone shoved into it. Move the effort of maintaining kdebuild
101 bits to those who are responsible for it, effectively.
104 > > Finally, and I admit this is a bit barbed- any user who install this
105 > > eapi should've known it was experimental and that they could get
106 > > support for it for paludis only. If the user thought it was someday
107 > > going to become an official eapi, that's the user/managers problem,
108 > > not ours.
109 >
110 > kdebuild-1 was not experimental. It was an official Gentoo KDE project
111 > EAPI.
113 Goodie on them. Note that it's "official gentoo kde project", not
114 "official eapi".
116 Then they can maintain it w/ paludis, rather then the current PMS
117 incarnation being stuck with it.
120 > > More importantly, pms's responsibility/purpose for gentoo is
121 > > presenting users with documentation on the *official* eapis- forcing
122 > > kdebuild bits into that doc misleads users into thinking kdebuild is
123 > > official, thus supported. User confusion there is, and has been,
124 > > rather annoying.
125 >
126 > And at the time, the Gentoo KDE project considered kdebuild-1 to be an
127 > official EAPI.
129 And they have zero ability to define what is an official EAPI.
130 Misunderstanding reality bluntly, is their problem.
132 As I said, are we on the hook if gnome decides they want their own
133 format? No.
135 Further, note prefix- that is a far more widespread deployment of an
136 experimental eapi, longer lived (and still living even). PMS ain't on
137 the hook for their experimental work- they went and got it approved as
138 an EAPI, for the new EAPI pms is *now* on the hook.
140 That's the proper way to have an official eapi. Someone
141 misunderstanding reality, or misrepresenting reality and claiming an
142 experimental eapi is 'official' is not our problem, and not even
143 remotely something we should be bound by.
145 I'll note finally that when gentoo-kde went and had their brief liason
146 w/ kdebuild, the issues of long term support of the format were known-
147 further it was made abundantly clear to them that from portage/pkgcore
148 standpoint it was an experimental eapi and there wasn't a gurantee
149 we'd ever implement it (in my case I'm reasonably sure the phrase
150 "when hell freezes over" was uttered more then once).
152 I'm sorry if this causes folks any issue, but both paludis and
153 gentoo-kde knew what they were getting into when they went down this
154 path. Frankly I really don't think any users are going to be affected
155 by punting this out of PMS- paludis still carries the support (and is
156 the users only option from day one for removing those packages)
158 You're arguing this must remain in PMS so that folks implementing
159 managers can see it. Nobody is going to implement kdebuild- at best I
160 may write a converter just to bail those users out, but that's likely
161 the extent of effort people will extend on cleaning it up.
163 Beyond that, a compromise was offered so that experimental eapis, and
164 dead/old eapis can be retired from the document.
166 Gentoo doesn't really even need to do that- that's just an attempt to
167 be nice and compromise. If that's not good enough, frankly, tough
168 cookies from where I'm sitting.
170 ~harring


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