Gentoo Archives: gentoo-pms

From: Ciaran McCreesh <ciaran.mccreesh@××××××××××.com>
To: Brian Harring <ferringb@×××××.com>
Cc: gentoo-pms@l.g.o
Subject: Re: [gentoo-pms] kdebuild-1 conditionales
Date: Fri, 11 Dec 2009 22:06:43
Message-Id: 20091211205417.77c2d31c@snowmobile
In Reply to: Re: [gentoo-pms] kdebuild-1 conditionales by Brian Harring
1 On Fri, 11 Dec 2009 12:30:22 -0800
2 Brian Harring <ferringb@×××××.com> wrote:
3 > > No, if a large project such as, say, the Gentoo KDE project, had
4 > > asked you for support for a well documented EAPI and you had
5 > > provided it, I would have also implemented that EAPI in Paludis.
6 > >
7 > > kdebuild-1 was not done without consultation. It was the result of a
8 > > considerable amount of work from an official Gentoo project, and it
9 > > was a well defined, published standard. It was in no way an
10 > > experiment.
11 >
12 > And if gnome decides they want their own format, is PMS/eapi stuck w/
13 > the bill?
14
15 If the Gentoo Gnome project produces their own documented format, then
16 yes, I'd expect the Gentoo PMS project to do everything it can to help
17 them with that if that was their desire. I would not expect the Gentoo
18 PMS project to say to the Gentoo Gnome project "no, go away, we're not
19 helping you".
20
21 > > > Regardless, if you didn't plan for phasing out an experimental
22 > > > eapi, it's not the mainstream eapi's problem- it's your mess to
23 > > > clean up.
24 > >
25 > > kdebuild-1 was not experimental.
26 >
27 > It wasn't official, thus *you* can view it was non-experimental w/in
28 > the paludis realm, but it's experimental to gentoo as a whole- the
29 > primary pkg manager, the official manager specifically, didn't even
30 > support it.
31 >
32 > It was experimental.
33
34 No, it was a published standard.
35
36 > PMS was irresponsible for allowing it into the official eapis in the
37 > first place. If KDE intended it to be supported long term (which I
38 > strongly doubt, it was an overlay of unstable ebuilds after all),
39 > then they too were irresponsible.
40
41 It is not the place of the Gentoo PMS project to tell Gentoo developers
42 to sod off when they ask for help.
43
44 > > Writing a converter is more work than a simple phased removal.
45 >
46 > I didn't imply a full format converter. I implied a converter that
47 > tweak it enough the thing could be uninstalled by *any* package
48 > manager supporting eapi2. I'd expect that would cover a significant
49 > majority of any remaining (if even there are remaining) installed
50 > pkgs.
51
52 Again, more work than a simple phased removal.
53
54 > > > That solves it technically, rather then just ignoring it and
55 > > > pretending we won't have this exact discussion a year later w/
56 > > > the same claims as to why it can't be removed.
57 > >
58 > > A year later, we can easily have had kdebuild-1 removed in a
59 > > responsible manner.
60 >
61 > You have zero stats now to backup that statement- basically your
62 > prediction of when it'll be fine to remove it is based on opinion.
63 >
64 > Via the same rules, my opinion is that it's fine to remove it now. 1
65 > -1 = 0.
66 >
67 > Back this up w/ stats please in the future.
68
69 My proposed phasing out will take two Paludis major releases. That's
70 considerably less than a year.
71
72 > > More work than just doing it properly.
73 >
74 > Depends on your definition of 'properly'. I presume what you mean is
75 > that it requires you to maintain a kdebuild pms pdf somewhere- more
76 > work for you.
77
78 No, it requires just not removing anything for a bit longer.
79
80 > My stance, it's more work for the rest of us coding around the ifdef
81 > mess (most recent bitchfest from it was grobian doing the prefix
82 > patch).
83
84 Then ask the Council to let us just leave it in without ifdefs until
85 the phased removal is complete. Simple.
86
87 > Properly to me means using the dvcs's capabilities, and making it
88 > easier for folks to do *official* eapi work w/out having to maintain
89 > dross someone shoved into it. Move the effort of maintaining
90 > kdebuild bits to those who are responsible for it, effectively.
91
92 Using git's capabilities is something you do if and only if you can't
93 use native capabilities. You don't see a million different versions of
94 the Linux kernel, each containing different configuration settings with
95 all the #ifdefs removed...
96
97 > > kdebuild-1 was not experimental. It was an official Gentoo KDE
98 > > project EAPI.
99 >
100 > Goodie on them. Note that it's "official gentoo kde project", not
101 > "official eapi".
102
103 Are you saying that the Gentoo PMS project should tell other Gentoo
104 developers to go away when they ask for help?
105
106 > > And at the time, the Gentoo KDE project considered kdebuild-1 to be
107 > > an official EAPI.
108 >
109 > And they have zero ability to define what is an official EAPI.
110 > Misunderstanding reality bluntly, is their problem.
111
112 Are you saying that the Gentoo PMS project should overrule GLEP 39?
113
114 > Further, note prefix- that is a far more widespread deployment of an
115 > experimental eapi, longer lived (and still living even). PMS ain't
116 > on the hook for their experimental work- they went and got it
117 > approved as an EAPI, for the new EAPI pms is *now* on the hook.
118
119 Prefix never had an official, stable specification, which was all that
120 kept it out of PMS.
121
122 Again, you still haven't said what's wrong with doing a clean, phased
123 withdrawal. This looks a lot like you're jumping on the "let's try to
124 cause trouble and disrupt things" bandwagon here.
125
126 --
127 Ciaran McCreesh

Attachments

File name MIME type
signature.asc application/pgp-signature