Gentoo Archives: gentoo-dev

From: Alec Warner <antarus@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] My wishlist for EAPI 5
Date: Thu, 21 Jun 2012 09:28:19
Message-Id: CAAr7Pr_RUB+W2Kx=oivkxZqy6u3v_CoWN_O=jaEanVsAK10Gjg@mail.gmail.com
In Reply to: Re: [gentoo-dev] My wishlist for EAPI 5 by Pacho Ramos
1 On Thu, Jun 21, 2012 at 9:25 AM, Pacho Ramos <pacho@g.o> wrote:
2 > El jue, 21-06-2012 a las 08:00 +0100, Ciaran McCreesh escribió:
3 >> On Thu, 21 Jun 2012 08:08:55 +0200
4 >> Pacho Ramos <pacho@g.o> wrote:
5 >> > Also, if I remember correctly, Tommy asked for this some months ago,
6 >> > you asked for what he sent some days ago and now you require more and
7 >> > more work to delay things to be implemented.
8 >>
9 >> I still haven't seen a clear description of exactly what should be
10 >> changed and why. I've also not seen a description of exactly what
11 >> problem is being solved, nor a discussion of the relative merits of
12 >> implementing a solution to whatever that problem is. All I've seen is a
13 >> mess of code that "gets it working" in Portage (which isn't the same as
14 >> "implements it for Portage") and a big wall of text that contains lots
15 >> that no-one needs to know and little of what's important. This needs to
16 >> go through the GLEP process, and it needs a PMS diff.
17 >>
18 >> In case you're not aware, the first time Gentoo did multilib, it was
19 >> done as a series of random changes to Portage that no-one really
20 >> thought through or understood. As you can see, that didn't work...
21 >>
22 >
23 > Then, looks clear to me that the way to get things approved in newer
24 > EAPIs is not clear enough as looks like a lot of devs (like me) don't
25 > know them (for example, when things to be added to EAPI need also a GLEP
26 > and a PMS diff, also the needing to get an implementation for any
27 > package manager). Is this documented in some place? If not, I think it
28 > should be documented and, of course, it should be done by PMS team if
29 > possible as they clearly know what they expect to get for approval if
30 > needed since, I discussed some days ago, council will simply accept some
31 > specific features to be included in next eapi once they are accepted by
32 > PMS team. That way, we could save a lot of time, know what steps are
33 > pending, try to ask for help for some specific steps and, finally, get
34 > it discussed in PMS people providing all what is needed.
35 >
36 >
37 >> > I also don't understand why Gentoo is forced to stick with old ways
38 >> > of doing things until new EAPI is approved
39 >>
40 >> That's not what's going on here. The issue is that there might be one
41 >> person who understands what "the new way of doing things", but he
42 >> hasn't told us what he thinks that is. Once we get a proper
43 >> explanation, getting an EAPI out doesn't take long.
44 >>
45 >
46 > But you must confess that old problems like multilib support, force
47 > package rebuilding or optional dep support are still pending while still
48 > needing and, the problem with the way things are discussed now is that
49 > some day anybody arises the problem again, other one demands more things
50 > to be provided, a discussion starts, the problem gets stalled... one
51 > year later the same problem arises again. There is clearly a lack of
52 > information to the rest of developers about how to propose anything to
53 > get accepted for next EAPI.
54
55 I'm not following you here.
56
57 1) Usually features need a reference implementation.
58 2) For portage, there are like 3-5 people who know portage well enough
59 to write that for you.
60 3) You generally have to convince them to do it before you can move forward.
61 4) Most features never even get a reference implementation.
62
63 There is this vague idea that you can just propose something; get
64 consensus on the ML, everyone goes to implement it, and then it works
65 just as designed. That is usually called the 'waterfall' model and its
66 really hard to do correctly.
67
68 What I imagine the process is:
69
70 1) Submit an idea to the ML; you just need feedback (not consensus,
71 which is likely impossible for non-trivial ideas.)
72 1.1) Your idea could be a GLEP, but I don't think a GLEP is strictly required.
73 2) Take feedback from step one and make an initial implementation. You
74 will likely find some assumptions in your 'design' from step one were
75 wrong, as well as other implementation issues (UI, performance, etc.)
76 3) Modify your idea to address the problems in 2.
77 4) Modify your implementation to address the problems in 2.
78 5) Repeat steps 2-4 a few times until you have solved all the 'big' problems.
79 6) Submit a diff to PMS outlining how the package manager behavior is
80 changed by your feature. This generally needs to be specific enough so
81 that other package manager authors can implement the feature.
82 7) Submit a devmanual patch telling users how to use the feature.
83
84 Most people fail at step two; usually because they try to get
85 'consensus' at step one, which is stupid and a waste of time. There
86 are a few hundred people on this list; we will never all agree, on
87 basically anything. So take the feedback people give you and do
88 something with it.
89
90 >
91 >> The main problem here isn't even EAPI related. Ebuild developers don't
92 >> even know what they'll be expected, required or able to do for multilib.
93 >>
94 >> > while Exherbo is free to implement and use things like that special
95 >> > way of handling DEPENDENCIES without waiting for any EAPI to be
96 >> > accepted...
97 >>
98 >> The DEPENDENCIES proposal predates Exherbo. Gentoo originally didn't
99 >> have it because Portage couldn't implement it. Now it doesn't have it
100 >> because it's too controversial to get it approved.
101 >
102 > It was only a example, but thanks for the info :)
103 >
104 >> Exherbo does have it
105 >> because it was carefully discussed, compared to alternatives, planned
106 >> out, tested, accepted by the expendable figurehead, and then rolled out.
107 >>
108 >> > or maybe I am wrong and people is able to use any PM manager
109 >> > compliant with EAPI on exherbo without issues?
110 >>
111 >> If anyone ever manages to come up with another package mangler that can
112 >> get close to implementing what Exherbo needs, then sure.
113 >>
114 >
115 > Then, you accept exherbo is not forced to *only* follow EAPI while you
116 > force Gentoo and portage to only support features approved in an EAPI?
117 >
118
119 Portage can use whatever EAPIs portage wishes to publish (Zac has
120 published portage specific EAPIs in the past.) Generally in gentoo-x86
121 you can only use council approved EAPIs; so if portage was to publish
122 something like 'portage-1' you would have to get council approval to
123 use it in Gentoo-x86. It seems like a reasonable request to me, why
124 not talk to them about it.
125
126 The reason exherbo can 'do whatever they want' is because the project
127 is marketed that way. Seriously, go to Exherbo.org and look at the
128 'Why' section. Reason 2 is 'we need to break stuff whenever we feel it
129 is beneficial.' Gentoo is not marketed that way to our users. We
130 'generally promise' backwards compat for 6-12 months.
131
132 If we randomly added stuff to portage without being bound by EAPI then
133 we end up breaking stuff unintentionally all the time when rolling out
134 features.
135
136 -A

Replies

Subject Author
Re: [gentoo-dev] My wishlist for EAPI 5 Rich Freeman <rich0@g.o>
Re: [gentoo-dev] My wishlist for EAPI 5 Pacho Ramos <pacho@g.o>