1 |
Pacho Ramos schrieb: |
2 |
> El vie, 19-10-2012 a las 22:39 +0200, Thomas Sachau escribió: |
3 |
>> Pacho Ramos schrieb: |
4 |
>>> El vie, 19-10-2012 a las 21:43 +0200, Thomas Sachau escribió: |
5 |
>>>> Pacho Ramos schrieb: |
6 |
>>>>> I volunteer to do whatever conversions you want for every ebuild I find |
7 |
>>>>> if I have time... what prevents me from doing it is to commit that |
8 |
>>>>> changes to ebuilds not maintained by me and not knowing if developers |
9 |
>>>>> agree on using latest eapi if possible. A more general solution (or |
10 |
>>>>> policy) needs to be worked as, otherwise, tree won't be moved to latest |
11 |
>>>>> eapi ever because we would need to: |
12 |
>>>>> - Periodically send bugs + patches |
13 |
>>>>> - Ask for permission to commit |
14 |
>>>>> |
15 |
>>>>> And that for every eapi bump |
16 |
>>>>> |
17 |
>>>> |
18 |
>>>> Either an ebuild has a responsive maintainer, which you can ask friendly |
19 |
>>>> to bump the EAPI because of feature X you would like to use or there is |
20 |
>>>> no maintainer, in which case you are free to touch/bump or last rite the |
21 |
>>>> ebuild. |
22 |
>>>> |
23 |
>>>> So i still dont see any need or requirement for a policy to |
24 |
>>>> force/require all devs to always use or switch to the latest avaidable |
25 |
>>>> EAPI. As already written in this thread, it would just mean less new |
26 |
>>>> ebuilds and less version bumps with such a policy. And i also prefer |
27 |
>>>> more work done with older EAPI versions around then less ebuilds/new |
28 |
>>>> versions with latest EAPI. |
29 |
>>>> |
30 |
>>> |
31 |
>>> Seriously, what people is still having problems with handling eapi4? If |
32 |
>>> there are doubts about its usage, they should be asked and resolved |
33 |
>>> instead of ignored keeping ebuilds with older eapis. The only eapi that |
34 |
>>> probably adds no advantage for a lot of ebuilds is eapi3, but that is |
35 |
>>> not the case for eapi4 for example, that includes changes that should be |
36 |
>>> incorporated by most packages in the tree, some of them introduced by it |
37 |
>>> and others inherited from older eapis. |
38 |
>>> |
39 |
>>> What is the advantage of using eapi2 over eapi4 for example? What "hard |
40 |
>>> to learn" change was included in eapi4 over eapi2? |
41 |
>>> |
42 |
>> |
43 |
>> This is not about "having problems with handling eapi-X", this is just |
44 |
>> about limited time and the choice where to spend that time. If you do |
45 |
>> just a version bump, you often dont have to touch the ebuild at all, |
46 |
>> just copy, test, commit and be happy. If you additionally require an |
47 |
>> EAPI bump, this means to carefully check the ebuild, adjust it to the |
48 |
>> new EAPI and additionally check, that the expected haviour is also the |
49 |
>> one that happens. While doing this, i could also have fixed another bug |
50 |
>> or have done another version bump. And that was already expressed in my |
51 |
>> first response. I nowhere claimed to have problems with EAPI bumps, just |
52 |
>> that they require additional time, so reducing the amount of time left |
53 |
>> to create new ebuilds/fix bugs/do version bumps. And with the choice, i |
54 |
>> prefer the new ebuilds/fixed bugs/version bumps over an ebuild switched |
55 |
>> to a new EAPI. |
56 |
>> |
57 |
>> So my question to you: What is the advantage of using ${NEW_EAPI} over |
58 |
>> using ${OLDER_EAPI}, when the ebuild does the same and the result is the |
59 |
>> same? |
60 |
>> |
61 |
> |
62 |
> I already explained the advantages, simply take a look to: |
63 |
> http://devmanual.gentoo.org/ebuild-writing/eapi/index.html |
64 |
> |
65 |
> to see that, for example, --disable-dependency-tracking won't be used by |
66 |
> default for older eapis. The same will occur with eapi5 and |
67 |
> --disable-silent-rules or running tests in parallel. |
68 |
> |
69 |
> That time you think you are saving, will be need to be lost if, for |
70 |
> example, some QA policy appears in the future to move to try to run |
71 |
> tests in parallel when possible, or force verbose output. |
72 |
> |
73 |
|
74 |
Please remember, that not every package out there does use an autotools |
75 |
based build system, we also have custom configure scripts, custom |
76 |
makefiles, things like cmake, qmake or even completly different things |
77 |
like ant based build systems for java. All those build systems wont |
78 |
benefit neither from --disable-dependency-tracking nor from |
79 |
--disable-silent-rules. |
80 |
|
81 |
Also, as already pointed out, a package, which currently exists may be |
82 |
unmaintained and useless in the future, so if i dont do the work now and |
83 |
remove the then unneeded package later, i did not spend any additional |
84 |
time for this change. Your requirement would either mean wasted time or |
85 |
another open bug until the package gets removed. |
86 |
|
87 |
Beside that, i did ask you about the case, where "the ebuild does the |
88 |
same and the result is the same". And you did not answer my question, |
89 |
why an EAPI-bump in such cases should be done. |
90 |
|
91 |
And finally, as already pointed out by Rich, you should not talk about |
92 |
any specific EAPI you like/prefer/want to be used everyhwere, but |
93 |
instead about the issue you want to solve. So just point out the issue |
94 |
and ask the maintainer to fix it. If he uses a newer EAPI, good. If he |
95 |
uses another solution, which also fixes the issue, also good. We should |
96 |
not discuss about a specific way to solve some issues, since this is the |
97 |
maintainers choice. Our goal should instead be to fix as many issues as |
98 |
possible with our limited amount of time we have for Gentoo. |
99 |
|
100 |
|
101 |
-- |
102 |
|
103 |
Thomas Sachau |
104 |
Gentoo Linux Developer |