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 20:19:43
Message-Id: 20091211194241.GF6529@hrair
In Reply to: Re: [gentoo-pms] kdebuild-1 conditionales by Ciaran McCreesh
1 On Fri, Dec 11, 2009 at 06:27:39PM +0000, Ciaran McCreesh wrote:
2 > On Fri, 11 Dec 2009 19:14:39 +0100
3 > The impact is that those of us using PMS for developing a package
4 > manager have to go back and change it.
6 Not really.
8 Paludis is, and was, the only one that supported kdebuild. Meaning
9 any user of kdebuild is *already* bound to paludis- again, bluntly,
10 this is a paludis specific mess. If I ever write anything kdebuild
11 specific, it would be a converter- this is something the paludis folk
12 should be doing if they're really concerned about users still running
13 kdebuild (since you'd just have to focus on *rm phases, it's pretty
14 straightforward).
16 Bluntly, you would be pissed if you got stuck having long term support
17 for an experimental eapi I split w/out consult- why do you think that
18 the reverse wouldn't hold? My point here is that pkgcore won't be
19 implementing kdebuild anytime soon, nor would I expect portage ever to
20 do so. At best, a converter might be written, but that's it- I'm not
21 going to put time into a dead format for a mess that isn't mine,
22 essentially.
24 Regardless, if you didn't plan for phasing out an experimental eapi,
25 it's not the mainstream eapi's problem- it's your mess to clean up.
26 If the user goes and installs something experimental/unsupported,
27 that's their issue- the folks they can yell at are their upstream
28 (the manager in this case, and gentoo kde).
30 If we did as you asked, we would have to document every pre eapi
31 portage has had (at least 8 off the top of my head), the previous
32 iterations of prefix, and realistically, the exherbo format should
33 some user manage to install an exheres-0 build into a gentoo box.
34 This *is* the case- it's applying the same logic you're using for
35 trying to keep kdebuild-1 in.
37 What I find pointless about this discussion is this notion that
38 because you jammed kdebuild into the official eapi doc, the pms team
39 in it's current incarnation is responsible for keeping kdebuild
40 around and cleaning up that mess.
43 The proper cleanup if you really wanted this done is the following:
44 1) add warnings into paludis if kdebuild is detected installed,
45 telling them to upgrade/remove whatever, and/or-
46 2) write a converter. As said, since it's only *rm phases you really
47 have to care about for allowing it to be removed by other managers,
48 this isn't incredibly hard- further, full metadata rewrite is probably
49 possible w/ eapi2 bits.
50 3) send out notifications via paludis lists, channels, whatever-
51 basically since this is paludis specific, use those mediums to contact
52 people and let them know the experiment is dead (they should be
53 listening on those mediums anyways).
55 That solves it technically, rather then just ignoring it and
56 pretending we won't have this exact discussion a year later w/ the
57 same claims as to why it can't be removed.
59 Additional thing- note the compromise I mentioned, adding into PMS
60 urls directing users where to go for experimental format information,
61 or to get at old/dead official eapis. If they can't catch a
62 paragraph upfront telling them where to look, it's their problem.
64 Meanwhile, you can maintain the ifdef'd bits in your own branch- hell,
65 just a copy of the existing pms pdf would suffice since kdebuild is a
66 locked/dead format anyways.
68 Finally, and I admit this is a bit barbed- any user who install this
69 eapi should've known it was experimental and that they could get
70 support for it for paludis only. If the user thought it was someday
71 going to become an official eapi, that's the user/managers problem,
72 not ours.
74 Our problem, and our sole area of responsibility , is the latex
75 obfuscation mess- via git, shifting of maintenance of the kdebuild
76 spec to paludis is easy.
78 More importantly, pms's responsibility/purpose for gentoo is
79 presenting users with documentation on the *official* eapis- forcing
80 kdebuild bits into that doc misleads users into thinking kdebuild is
81 official, thus supported. User confusion there is, and has been,
82 rather annoying.
84 ~harring


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