Gentoo Archives: gentoo-council

From: Ciaran McCreesh <ciaran.mccreesh@××××××××××.com>
To: Mike Frysinger <vapier@g.o>
Cc: gentoo-council@l.g.o, Ulrich Mueller <ulm@g.o>, Brian Harring <ferringb@×××××.com>, gentoo-pms@l.g.o
Subject: Re: [gentoo-council] Re: [gentoo-pms] kdebuild-1 conditionales
Date: Mon, 14 Dec 2009 18:21:42
Message-Id: 20091214182129.159de745@snowcone
In Reply to: Re: [gentoo-council] Re: [gentoo-pms] kdebuild-1 conditionales by Mike Frysinger
1 On Mon, 14 Dec 2009 12:01:03 -0500
2 Mike Frysinger <vapier@g.o> wrote:
3 > > > i'm talking about when this crap was added originally, not any
4 > > > recent conversations
5 > >
6 > > That was when it was added.
7 >
8 > and ? it should have been deleted then and it should be deleted now.
9
10 Not what the Council said. Your personal opinion wasn't what was voted.
11
12 > > Keeping it around without a specification is a bad idea. And no, the
13 > > plan is not to keep it anywhere forever. The plan is to keep it
14 > > around until we can ensure that users aren't going to be affected
15 > > by the removal.
16 >
17 > which is irrelevant to the PMS. fact is, only your PM supports it
18 > and no one is telling you what to do with your PM. correctly
19 > removing it from PMS wont affect any user whatsoever. absolutely no
20 > users would be affected by cleaning up the PMS git tree.
21
22 As has already been explained, keeping the spec around is a necessary
23 part of keeping the implementation around.
24
25 > > > it is after all your own fault.
26 > >
27 > > For helping the Gentoo KDE team out? I'll bear that in mind next
28 > > time Gentoo developers want help with something.
29 >
30 > what wonderful slant you have. you didnt work with the KDE team out
31 > of the kindness of your heart, you worked with developers who were on
32 > your side and controlled significant stack of Gentoo ebuilds that
33 > users relied on. their only option to use the bleeding edge was to
34 > switch to your PM.
35
36 No, I worked with developers who asked me for help, and I gave them
37 what they asked for, after insisting that it was done as a public,
38 documented standard precisely to avoid it by necessity being restricted
39 to a single package manager. That you don't like a decision made by a
40 Gentoo project is your problem.
41
42 > as for "it's what the official KDE docs said", that too is complete
43 > bs. there are teams with more important ebuilds that have
44 > instructions that only work with portage.
45
46 I highly doubt that, since if that were the case we'd be receiving
47 reports from users about it.
48
49 > if anyone tried to add these to the PMS, you'll fully bitch and moan
50 > and block it from ever making it into the PMS. some of these rely on
51 > portage behavior with the environment and some of these rely on
52 > behavior portage has had for years (and before the PMS).
53
54 Er, no. If that were the case, users wouldn't be able to use Paludis.
55
56 > > Uh. Riiiiight. I'm just drowning in bug reports from users who're
57 > > using ebuilds that break with Paludis because we haven't
58 > > implemented things that've been used in the tree for years. Perhaps
59 > > you'd care to back up your mud-slinging with some examples.
60 >
61 > stop with your misdirection bullshit. you know plenty of examples.
62 > then again, your style is to keep whining that you arent aware of
63 > anything until someone explicitly mentions them, so there's prep*,
64
65 prep* can't go in since what it does has yet to be locked down or
66 guaranteed. We can't spec it as "does something arbitrary", yet that's
67 all prep* is guaranteed to do. And, as you know, EAPI 4 has had
68 features added to it to give you what you were after, except done in a
69 well defined manner.
70
71 > FEATURES
72
73 There is no legitimate use for FEATURES in the tree, since something
74 being in FEATURES only indicates that the user asked for it, not that
75 it is enabled. For example, ebuilds that do has userpriv $FEATURES are
76 broken, because userpriv in features does not mean that userpriv has
77 actually been enabled by Portage.
78
79 > and CBUILD/CTARGET in econf to mention a few.
80
81 Could you point me to the bug for that one please? I think I can see
82 what PMS might be missing on that one, but I don't recall ever seeing a
83 bug about it, or what the conclusion was. I also can't find the bug by
84 searching for comments containing all of the words "pms ctarget", or
85 "pms cbuild".
86
87 > > > yet crap that was explicitly never official or in used in the tree
88 > > > you feel you have a right to keep in the PMS.
89 > >
90 > > It was added at the request of the Gentoo KDE team. It wasn't added
91 > > because I wanted it; it was added because Gentoo developers asked
92 > > for it. I realise you like to pretend that the people who asked for
93 > > it never existed, but the fact is they did, and it would be
94 > > irresponsible of Gentoo to make users suffer because of internal
95 > > politicking.
96 >
97 > great ! so when are you going to add these features that have
98 > existed for years in portage to the PMS ? your logic is complete
99 > crap.
100
101 If you want FEATURES to be able to be used reliably by ebuilds, you'll
102 have to get the Portage people to implement that in a new EAPI first.
103
104 If you want prep*, you'll have to ask the Portage people to guarantee
105 that they'll stop changing what it does so we can spec it in in a new
106 EAPI. However, since EAPI 4 includes a well defined alternative to
107 prep* abuse, there's probably no need.
108
109 I'll give you an answer for CHOST / CTARGET when you point me to the
110 bug for it, since I can't find it myself and I can't recall what the
111 conclusion was.
112
113 > > > it doesnt belong there, it never has, so delete it/branch it
114 > > > already.
115 > >
116 > > You still haven't explained why it's better to delete it now than
117 > > to do a controlled removal that won't affect users.
118 >
119 > and you have yet to show how your PM behavior is relevant one bit to
120 > the PMS here. removing unofficial crap from the PMS has no bearing
121 > whatsoever on ebuilds that require unofficial PMs. keep the crap in
122 > your PM forever for all i care.
123
124 Uh. See earlier emails in the thread.
125
126 --
127 Ciaran McCreesh

Attachments

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

Replies

Subject Author
Re: [gentoo-council] Re: [gentoo-pms] kdebuild-1 conditionales Mike Frysinger <vapier@g.o>