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