1 |
On Fri, 6 Aug 2010 11:18:46 -0700 |
2 |
Brian Harring <ferringb@×××××.com> wrote: |
3 |
> And by "right now", I assume you meant to say "minimally a year down |
4 |
> the line after a portage is stabled supporting g55 semantics and |
5 |
> resolving any breakage it's usage induces". You know, the same issue |
6 |
> EAPI itself had to go through to ensure that people had a reasonable |
7 |
> chance of getting an appropriate error message and support being in |
8 |
> place. |
9 |
|
10 |
Uh, no, since GLEP 55 doesn't need users to be using a newer Portage. |
11 |
That is one of the many ways in which it is a much better solution. |
12 |
|
13 |
> New version formats aren't magically usable the moment g55 lands. At |
14 |
> the very least you're forgetting about bundled glsa's and their |
15 |
> knowledge of atom formats. |
16 |
> |
17 |
> Suppose the next comment will be "they suck, throw them out", but so |
18 |
> it goes. |
19 |
|
20 |
No, the fix is to give them EAPI suffixes too. |
21 |
|
22 |
> Realistically, 'the fact is' that a specific scm tag is preferable to |
23 |
> -9999. The reality is that people and the tools have been working |
24 |
> around it without huge issues for a long while. |
25 |
> |
26 |
> Would it be nice having some -scm tag? Sure. Is it worth the |
27 |
> disruption impementing it, and it's dependencies requires? That |
28 |
> arguement you've still not managed to convince people of. |
29 |
|
30 |
...and 1.2-3 and 1.2-alpha3 style versions, and so on. |
31 |
|
32 |
Remember, it's only a disruption to implement it without GLEP 55. |
33 |
|
34 |
> The restrictions are "no new global functionality can set or |
35 |
> influence EAPI". Basically the same restriction you forced on |
36 |
> eclasses. It's nasty and arbitrary when I state it, but some how it |
37 |
> is sane when you propose it the same thing? |
38 |
|
39 |
No, they're not. The restrictions are "no changes that will make older |
40 |
package managers not realise that the EAPI was supposed to have been set |
41 |
to something else". That's not the same thing at all, especially on the |
42 |
"using new Bash syntax" front, and the very fact that you missed that |
43 |
point just goes to illustrate the difficulties involved. |
44 |
|
45 |
> The thing you're ignoring out of this g55 idiocy is that people don't |
46 |
> particularly seem to want it. There has been an extremely vocal |
47 |
> subgroup of paludis/exherbo devs pushing for it while everyone else |
48 |
> seems to have less than an interest in it. That's generalizing a |
49 |
> bit, but is reasonably accurate. |
50 |
|
51 |
Uh, no. Plenty of people want it. There has been an extremely vocal |
52 |
subgroup of people who will yell at anything they think is connected to |
53 |
the 'wrong people' pushing against it, thus making everyone else suffer. |
54 |
|
55 |
> _EITHER WAY_, rather than having g33 get beat down for unrelated |
56 |
> reasons by people screaming they want their pony/g55, g33 can proceed |
57 |
> despite claims to the contrary, and it doesn't require g55 as |
58 |
> ciaran/crew have claimed. |
59 |
|
60 |
But no-one except you wants GLEP 33. What people want is per-package |
61 |
eclasses *without* all the arbitrary restrictions in GLEP 33. |
62 |
|
63 |
-- |
64 |
Ciaran McCreesh |