1 |
On Fri, Aug 06, 2010 at 07:34:09PM +0100, Ciaran McCreesh wrote: |
2 |
> On Fri, 6 Aug 2010 11:18:46 -0700 |
3 |
> Brian Harring <ferringb@×××××.com> wrote: |
4 |
> > And by "right now", I assume you meant to say "minimally a year down |
5 |
> > the line after a portage is stabled supporting g55 semantics and |
6 |
> > resolving any breakage it's usage induces". You know, the same issue |
7 |
> > EAPI itself had to go through to ensure that people had a reasonable |
8 |
> > chance of getting an appropriate error message and support being in |
9 |
> > place. |
10 |
> |
11 |
> Uh, no, since GLEP 55 doesn't need users to be using a newer Portage. |
12 |
> That is one of the many ways in which it is a much better solution. |
13 |
|
14 |
Currently, a PM that doesn't support EAPI4 will tell you "there is a |
15 |
version available, but I don't support this- upgrade me". Versus |
16 |
current PM's + g55 == "I see no version". |
17 |
|
18 |
*addressing* that would be useful, rather than staying in g55 |
19 |
salesman mode. Like it or not, you switch out the compatibility |
20 |
mechanisms there are delays that go with it while waiting on the |
21 |
implementations to propagate. |
22 |
|
23 |
Now if your solution is "they don't see the version till they |
24 |
upgrade", fine, at least it's accurate and it's stated. This is a |
25 |
fair bit more useful than "there is no issue and it solves world |
26 |
hunger in it's spare time". Grok? |
27 |
|
28 |
|
29 |
> > New version formats aren't magically usable the moment g55 lands. At |
30 |
> > the very least you're forgetting about bundled glsa's and their |
31 |
> > knowledge of atom formats. |
32 |
> > |
33 |
> > Suppose the next comment will be "they suck, throw them out", but so |
34 |
> > it goes. |
35 |
> |
36 |
> No, the fix is to give them EAPI suffixes too. |
37 |
|
38 |
You checked existing glsa parser to see what they'll do if they get |
39 |
new attributes/tags jammed into the format? |
40 |
|
41 |
Verifying they'll actually ignore the extension is needed rather than |
42 |
hand wavey crap. I'd hope they don't go boom, but there have been |
43 |
issues in the past of this sort. |
44 |
|
45 |
News items are another one that come to mind. Last glance, there |
46 |
wasn't a tag that was jammed into it stating "to even interpret this |
47 |
atom you need to be at least eapi foo"- glep42 surely doesn't cover |
48 |
it. |
49 |
|
50 |
Meaning that a proper implementation will parse it, and quite likely |
51 |
go boom. Meaning either those new version schemes you want can't be |
52 |
used for at least a year in news items. |
53 |
|
54 |
EAPI suffixes addresses one problem. Pretending it solves all is |
55 |
invalid however- GLSA's at the very least probably will have problems, |
56 |
NEWS items most definitely will. |
57 |
|
58 |
|
59 |
> > The restrictions are "no new global functionality can set or |
60 |
> > influence EAPI". Basically the same restriction you forced on |
61 |
> > eclasses. It's nasty and arbitrary when I state it, but some how it |
62 |
> > is sane when you propose it the same thing? |
63 |
> |
64 |
> No, they're not. The restrictions are "no changes that will make older |
65 |
> package managers not realise that the EAPI was supposed to have been set |
66 |
> to something else". That's not the same thing at all, especially on the |
67 |
> "using new Bash syntax" front, and the very fact that you missed that |
68 |
> point just goes to illustrate the difficulties involved. |
69 |
|
70 |
My stating of restrictions is actually the accurate one. If the rules |
71 |
were what you stated, eclasses would be allowed to set EAPI. |
72 |
|
73 |
Point is, ebuild's set the EAPI themselves. Even your g55 proposal |
74 |
requires this explicitly via the file naming. |
75 |
|
76 |
EAPI in the ebuild combined w/ global functionality never being |
77 |
allowed to screw with EAPI means global scope functionality that |
78 |
doesn't set/influence EAPI is entirely valid. |
79 |
|
80 |
If you're going to claim otherwise, provide an example of per pkg |
81 |
eclasses that fit the requirements stated above that would result in |
82 |
an invalid EAPI. Take an existing ebuild out of the tree to prove |
83 |
it. |
84 |
|
85 |
As for bash syntax, that's wholy unrelated to g33. g33, like normal |
86 |
eclasses, is bound by bash syntax requirements of the current eapi |
87 |
docs. |
88 |
|
89 |
Now removing that limitation might be nice, but it's not core to |
90 |
providing the functionality- as such lay off the bash crap, it's a |
91 |
selling point of g55, it's orthogonal to g33 however. |
92 |
|
93 |
|
94 |
> > The thing you're ignoring out of this g55 idiocy is that people don't |
95 |
> > particularly seem to want it. There has been an extremely vocal |
96 |
> > subgroup of paludis/exherbo devs pushing for it while everyone else |
97 |
> > seems to have less than an interest in it. That's generalizing a |
98 |
> > bit, but is reasonably accurate. |
99 |
> |
100 |
> Uh, no. Plenty of people want it. There has been an extremely vocal |
101 |
> subgroup of people who will yell at anything they think is connected to |
102 |
> the 'wrong people' pushing against it, thus making everyone else suffer. |
103 |
|
104 |
And plenty of people hate it too, for the abuse of extensions. |
105 |
|
106 |
The knee jerk claim that the only people who oppose this glep are |
107 |
anti-paludis/exherbo fan boys is the _same_ *bullshit* black/white |
108 |
nonsense y'all railed about it in a seperate part of this thread. |
109 |
|
110 |
Occusing others of fanboy idiocy while pulling the same to excuse away |
111 |
peoples complaints with the glep is hypocritical bullshit. It's very, |
112 |
very tiring, and there are groups on boths sides who pull that shit. |
113 |
|
114 |
Simply put, behaviour of this sort results in people ignoring y'all. |
115 |
Frankly with good reason- may have technical points, but the |
116 |
signal to bullshit ratio is far too high with behaviour of that sort. |
117 |
|
118 |
|
119 |
> > _EITHER WAY_, rather than having g33 get beat down for unrelated |
120 |
> > reasons by people screaming they want their pony/g55, g33 can proceed |
121 |
> > despite claims to the contrary, and it doesn't require g55 as |
122 |
> > ciaran/crew have claimed. |
123 |
> |
124 |
> But no-one except you wants GLEP 33. What people want is per-package |
125 |
> eclasses *without* all the arbitrary restrictions in GLEP 33. |
126 |
|
127 |
Considering g33 in it's current form doesn't even lay out specifics of |
128 |
per-package eclasses (mabi is working up a glep on that), this is a |
129 |
bit of a bullshit statement. |
130 |
|
131 |
The sole restriction that has been stated thus far for discussion of |
132 |
per package eclasses is "no EAPI setting in the eclass". Labeling |
133 |
that an arbitrary restriction when _you_ pushed the same into global |
134 |
eclasses is at best hypocritical, at worst flat out lieing. |
135 |
|
136 |
Fact is, people want per package eclasses. |
137 |
Additional fact is that both forms of can't screw with EAPI. |
138 |
Final fact is that g55 isn't required for g33- and until you come up |
139 |
with actual, testable examples, I'm done correcting your |
140 |
misstatements. |
141 |
|
142 |
~harring |