1 |
Pacho Ramos schrieb: |
2 |
> El sáb, 20-10-2012 a las 16:09 +0200, Thomas Sachau escribió: |
3 |
>> Pacho Ramos schrieb: |
4 |
>>> El vie, 19-10-2012 a las 22:39 +0200, Thomas Sachau escribió: |
5 |
>>>> Pacho Ramos schrieb: |
6 |
>>>>> El vie, 19-10-2012 a las 21:43 +0200, Thomas Sachau escribió: |
7 |
>>>>>> Pacho Ramos schrieb: |
8 |
>>>>>>> I volunteer to do whatever conversions you want for every ebuild I find |
9 |
>>>>>>> if I have time... what prevents me from doing it is to commit that |
10 |
>>>>>>> changes to ebuilds not maintained by me and not knowing if developers |
11 |
>>>>>>> agree on using latest eapi if possible. A more general solution (or |
12 |
>>>>>>> policy) needs to be worked as, otherwise, tree won't be moved to latest |
13 |
>>>>>>> eapi ever because we would need to: |
14 |
>>>>>>> - Periodically send bugs + patches |
15 |
>>>>>>> - Ask for permission to commit |
16 |
>>>>>>> |
17 |
>>>>>>> And that for every eapi bump |
18 |
>>>>>>> |
19 |
>>>>>> |
20 |
>>>>>> Either an ebuild has a responsive maintainer, which you can ask friendly |
21 |
>>>>>> to bump the EAPI because of feature X you would like to use or there is |
22 |
>>>>>> no maintainer, in which case you are free to touch/bump or last rite the |
23 |
>>>>>> ebuild. |
24 |
>>>>>> |
25 |
>>>>>> So i still dont see any need or requirement for a policy to |
26 |
>>>>>> force/require all devs to always use or switch to the latest avaidable |
27 |
>>>>>> EAPI. As already written in this thread, it would just mean less new |
28 |
>>>>>> ebuilds and less version bumps with such a policy. And i also prefer |
29 |
>>>>>> more work done with older EAPI versions around then less ebuilds/new |
30 |
>>>>>> versions with latest EAPI. |
31 |
>>>>>> |
32 |
>>>>> |
33 |
>>>>> Seriously, what people is still having problems with handling eapi4? If |
34 |
>>>>> there are doubts about its usage, they should be asked and resolved |
35 |
>>>>> instead of ignored keeping ebuilds with older eapis. The only eapi that |
36 |
>>>>> probably adds no advantage for a lot of ebuilds is eapi3, but that is |
37 |
>>>>> not the case for eapi4 for example, that includes changes that should be |
38 |
>>>>> incorporated by most packages in the tree, some of them introduced by it |
39 |
>>>>> and others inherited from older eapis. |
40 |
>>>>> |
41 |
>>>>> What is the advantage of using eapi2 over eapi4 for example? What "hard |
42 |
>>>>> to learn" change was included in eapi4 over eapi2? |
43 |
>>>>> |
44 |
>>>> |
45 |
>>>> This is not about "having problems with handling eapi-X", this is just |
46 |
>>>> about limited time and the choice where to spend that time. If you do |
47 |
>>>> just a version bump, you often dont have to touch the ebuild at all, |
48 |
>>>> just copy, test, commit and be happy. If you additionally require an |
49 |
>>>> EAPI bump, this means to carefully check the ebuild, adjust it to the |
50 |
>>>> new EAPI and additionally check, that the expected haviour is also the |
51 |
>>>> one that happens. While doing this, i could also have fixed another bug |
52 |
>>>> or have done another version bump. And that was already expressed in my |
53 |
>>>> first response. I nowhere claimed to have problems with EAPI bumps, just |
54 |
>>>> that they require additional time, so reducing the amount of time left |
55 |
>>>> to create new ebuilds/fix bugs/do version bumps. And with the choice, i |
56 |
>>>> prefer the new ebuilds/fixed bugs/version bumps over an ebuild switched |
57 |
>>>> to a new EAPI. |
58 |
>>>> |
59 |
>>>> So my question to you: What is the advantage of using ${NEW_EAPI} over |
60 |
>>>> using ${OLDER_EAPI}, when the ebuild does the same and the result is the |
61 |
>>>> same? |
62 |
>>>> |
63 |
>>> |
64 |
>>> I already explained the advantages, simply take a look to: |
65 |
>>> http://devmanual.gentoo.org/ebuild-writing/eapi/index.html |
66 |
>>> |
67 |
>>> to see that, for example, --disable-dependency-tracking won't be used by |
68 |
>>> default for older eapis. The same will occur with eapi5 and |
69 |
>>> --disable-silent-rules or running tests in parallel. |
70 |
>>> |
71 |
>>> That time you think you are saving, will be need to be lost if, for |
72 |
>>> example, some QA policy appears in the future to move to try to run |
73 |
>>> tests in parallel when possible, or force verbose output. |
74 |
>>> |
75 |
>> |
76 |
>> Please remember, that not every package out there does use an autotools |
77 |
>> based build system, we also have custom configure scripts, custom |
78 |
>> makefiles, things like cmake, qmake or even completly different things |
79 |
>> like ant based build systems for java. All those build systems wont |
80 |
>> benefit neither from --disable-dependency-tracking nor from |
81 |
>> --disable-silent-rules. |
82 |
>> |
83 |
>> Also, as already pointed out, a package, which currently exists may be |
84 |
>> unmaintained and useless in the future, so if i dont do the work now and |
85 |
>> remove the then unneeded package later, i did not spend any additional |
86 |
>> time for this change. Your requirement would either mean wasted time or |
87 |
>> another open bug until the package gets removed. |
88 |
> |
89 |
> If the package is unmaintained it won't probably have a revision bump |
90 |
> and, then, eapi won't change, if any other needs to fix another bug and |
91 |
> also bumps eapi, that package will be enhanced, that is what really |
92 |
> matters. If it's broke because dev bumping it failed to bump the eapi, |
93 |
> lets fix it (or ask for help) to prevent him from doing that error |
94 |
> again. All are gains: package is improved and developer learns how to |
95 |
> handle new eapi |
96 |
|
97 |
Hope you dont mix threads, since i dont see any relation between a |
98 |
package being unmaintained, a revision bump and a changing EAPI. |
99 |
|
100 |
Beside that: |
101 |
|
102 |
A package not using the latest EAPI is not broken, please stop doing |
103 |
such claims. Additionally fixing an issue without also bumping the |
104 |
package to the latest EAPI is not an issue or error by itself either. |
105 |
|
106 |
> |
107 |
>> |
108 |
>> Beside that, i did ask you about the case, where "the ebuild does the |
109 |
>> same and the result is the same". And you did not answer my question, |
110 |
>> why an EAPI-bump in such cases should be done. |
111 |
> |
112 |
> What about the huge number of packages that would benefit from the bump? |
113 |
> Why ignore them because a few packages won't benefit. Think in changes |
114 |
> like src_configure phase addition, that most packages with benefit from |
115 |
> it. Also, this is not about blindly forcing people to use latest eapi |
116 |
> without even evaluating what improvements they have, this is about, for |
117 |
> example, forcing packages to use eapi4 because it includes a ton of |
118 |
> enhancements from eapi0 that most packages would benefit from. |
119 |
> |
120 |
>> |
121 |
>> And finally, as already pointed out by Rich, you should not talk about |
122 |
>> any specific EAPI you like/prefer/want to be used everyhwere, but |
123 |
>> instead about the issue you want to solve. So just point out the issue |
124 |
>> and ask the maintainer to fix it. If he uses a newer EAPI, good. If he |
125 |
>> uses another solution, which also fixes the issue, also good. We should |
126 |
>> not discuss about a specific way to solve some issues, since this is the |
127 |
>> maintainers choice. Our goal should instead be to fix as many issues as |
128 |
>> possible with our limited amount of time we have for Gentoo. |
129 |
>> |
130 |
>> |
131 |
> |
132 |
> I have already pointed multiple examples where bumping eapi will help to |
133 |
> improve things, not doing so because of that hypothetical problems you |
134 |
> think could occur only leads us to current situation: a ton of autotools |
135 |
> packages won't get --disable-silent-rules/--disable-dependency-tracking |
136 |
> improvements because people doesn't even try to bump eapi, some more |
137 |
> packages will hide utilities failing but not dying because of using old |
138 |
> eapis, inconsistent blockers handling around the tree due using |
139 |
> different eapis, packages still relying on dying in pkg_setup instead of |
140 |
> setting proper USE deps, packages still using dohard and dosed, html |
141 |
> files in /usr/share/doc being compressed because of old eapi usage, I |
142 |
> even noticed past week a package still using ebeep. |
143 |
|
144 |
I am not talking about hypothetical problems, i am talking about a real |
145 |
thing: my limited amount of free time i am able and willing to spend for |
146 |
Gentoo. And i prefer spending it on fixing real bugs over spending |
147 |
additional time to bump the EAPI just for fun. |
148 |
|
149 |
For the points you see issues with: |
150 |
- dont miss, that one can also add those configure options in an ebuild |
151 |
without the requirement to use the EAPI. |
152 |
-Utilities failing but not dying? Only certain helper functions will die |
153 |
with EAPI-4, nothing else. And if in doubt, just add a " || die" after |
154 |
every call and be done with it. So also not related to the EAPI. |
155 |
-blocker handling is done by the PM, not the ebuild, so if you have a |
156 |
patch for a better UI output, PM maintainers will probably happily apply |
157 |
it, when you provide it. |
158 |
-for a die in pkg_setup instead of a USE dependency: Both ways will |
159 |
prevent you from continuing, the second one only has a unified UI. |
160 |
-I dont see any real problem with dosed and dohard, they are just |
161 |
wrappers around sed and ln, so what would improve if someone replaces |
162 |
the wrappers with calls to the wrapped tools? |
163 |
|
164 |
We could continue forever with this examples, so i will shorten my point |
165 |
of view: |
166 |
|
167 |
If i want/need an option, i will add it to the ebuild. If an option i |
168 |
want requires a newer EAPI, i will use the newer EAPI. If the current |
169 |
EAPI does offer all i need, i wont spend any additional time on the EAPI |
170 |
bump. |
171 |
|
172 |
If you want to do it differently for the packages you maintain, fine. |
173 |
Just dont try to force your preferred EAPI-handling on everyone else. |
174 |
|
175 |
|
176 |
-- |
177 |
|
178 |
Thomas Sachau |
179 |
Gentoo Linux Developer |