Gentoo Archives: gentoo-project

From: Steven J Long <slong@××××××××××××××××××.uk>
To: gentoo-project@l.g.o
Subject: [gentoo-project] Re: Enough about GLEP5{4,5}
Date: Mon, 08 Jun 2009 18:19:43
1 Roy Bamford wrote:
3 > Rémi Cardona wrote:
4 >> Seriously, let's stop.
5 >>
6 >> This endless debate has gone on for waaay too long and it is just
7 >> plain
8 >> spam now.
9 >
10 > [snip]
11 >
12 >> Let's just all agree we've failed to reach a consensus and let's
13 >> spend time on something else.
14 >
15 I agree it's tiresome.
16 >
17 > I think that GLEP55 has failed so far because it has always been
18 > inadequately documented in the GLEP.
19 >
20 If the problem had been adequately communicated in the first place
21 (which is pretty much required for any proposal ime) instead of people
22 being told they "don't understand so go away" we could have agreed
23 then, that the issue was simply about knowing the EAPI before sourcing.
25 As it is, we _finally_ have grudging submission that tightening the PMS
26 to reflect QA reality works but is not "the best solution."
28 > The problem won't be addressed by spending time on something else.
29 > The one big problem needs to be broken down recursively into smaller
30 > problems that can be addressed individually, rather like a very old
31 > asteriods game.
32 >
33 Let's do that with a statement made in objection to just doing what
34 we're doing:
35 < ciaranm> NeddySeagoon: objectively, you have to either not change
36 version format rules ever, or force the package manager to open() every
37 ebuild rather than no ebuilds before it can find the best version of
38 something
40 (Even though the case for changing version format has not been made, the
41 argument applies to the other incompatible changes affecting global
42 environment.)
44 Firstly, and most significantly, this only applies when the mangler does
45 not have the ebuild metadata in cache. Bear in mind portage automatically
46 caches overlays under /var/cache/edb, and that we distribute a metadata
47 cache via rsync for the main tree, so interactive performance does not
48 suffer in any event.
50 Cache design is open to improvement. Once we've broken encapsulation, we
51 cannot take it back. And it WILL lead to maintenance headaches.
53 Secondly, for the mangler to determine the "best-visible", EAPI is not the
54 only item under consideration. So again, there is a lie implicit: whether
55 from cache or from file, the mangler will ALWAYS need some metadata on the
56 ebuilds; CPV + EAPI is insufficient.
58 At very best, all EAPI in filename (wherever it is) does, is limit the set
59 of ebuilds to those with a supported EAPI before the cache has to be
60 consulted. For Gentoo users (who update as recommended) using Gentoo
61 product, that's _every_ ebuild in the tree and overlays.
63 So what practically are we accomplishing for our users?
65 And how much developer time would be wasted to do so, and indeed has already
66 been wasted on this? Time that could be spent improving the cache, binhost
67 support, completing the ebuild spec, writing ebuilds, or just having a
68 life. ;)
70 [There's no reason a repo providing an overlay couldn't use an eapi file
71 the same as profiles (sorry I don't know if this is already done) for
72 experimental herd stuff.]
74 > If we get a solution, Gentoo can be first into the future again, if
75 > not, we will always be last out of the past.
76 >
77 > Gentoo needs a way to introduce new features without waiting over a
78 > year to provide backwards compatibility.
79 >
80 We already have it.
82 We just can't allow a new, incompatible EAPI until we have an upgrade
83 path agreed for people on older versions of portage than 2.2 whenever
84 that EAPI comes out.
86 Or we just agree that we're not bothered if they get not-so-friendly
87 error messages for ebuilds from overlays which happen to use the new
88 EAPI. After all, most people will be using the cache; it's important
89 to remember that, and that in that case, no sourcing will happen in
90 any event, and nor will any of those error messages. If they need an
91 ebuild using an unsupported EAPI, they'll get the "unsupported EAPI"
92 message.
94 If not, they get a grotty error message; so what? It's not going to break
95 anything and presumably they'd be on a deprecated profile in any case, so
96 would already have been shouted at in no uncertain terms about upgrading,
97 along with a url to consult.
99 The real problem that is glaringly obvious to any external is the process
100 that allows Gentoo to be deflected from its strategic interests for over a
101 year on a technically-lamentable proposal. I for one would like to know how
102 prospective Council members intend to address that.
104 (If you don't think it is a problem, please feel free to say so /without/
105 resorting to insult over reason. If you think the proposal had merit: how
106 come we've only now got agreement that easily-extractable EAPI works?)
108 --
109 #friendly-coders -- We're friendly but we're not /that/ friendly ;-)