Gentoo Archives: gentoo-dev

From: Ciaran McCreesh <ciaran.mccreesh@××××××××××.com>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] RFC: Reviving GLEP33
Date: Fri, 06 Aug 2010 18:34:49
Message-Id: 20100806193409.44493f15@snowcone
In Reply to: Re: [gentoo-dev] RFC: Reviving GLEP33 by Brian Harring
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

Attachments

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

Replies

Subject Author
Re: [gentoo-dev] RFC: Reviving GLEP33 Brian Harring <ferringb@×××××.com>