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 |