| 1 |
El sáb, 20-10-2012 a las 16:29 +0200, Pacho Ramos escribió: |
| 2 |
[...] |
| 3 |
> > And finally, as already pointed out by Rich, you should not talk about |
| 4 |
> > any specific EAPI you like/prefer/want to be used everyhwere, but |
| 5 |
> > instead about the issue you want to solve. So just point out the issue |
| 6 |
> > and ask the maintainer to fix it. If he uses a newer EAPI, good. If he |
| 7 |
> > uses another solution, which also fixes the issue, also good. We should |
| 8 |
> > not discuss about a specific way to solve some issues, since this is the |
| 9 |
> > maintainers choice. Our goal should instead be to fix as many issues as |
| 10 |
> > possible with our limited amount of time we have for Gentoo. |
| 11 |
> > |
| 12 |
> > |
| 13 |
> |
| 14 |
> I have already pointed multiple examples where bumping eapi will help to |
| 15 |
> improve things, not doing so because of that hypothetical problems you |
| 16 |
> think could occur only leads us to current situation: a ton of autotools |
| 17 |
> packages won't get --disable-silent-rules/--disable-dependency-tracking |
| 18 |
> improvements because people doesn't even try to bump eapi, some more |
| 19 |
> packages will hide utilities failing but not dying because of using old |
| 20 |
> eapis, inconsistent blockers handling around the tree due using |
| 21 |
> different eapis, packages still relying on dying in pkg_setup instead of |
| 22 |
> setting proper USE deps, packages still using dohard and dosed, html |
| 23 |
> files in /usr/share/doc being compressed because of old eapi usage, I |
| 24 |
> even noticed past week a package still using ebeep. |
| 25 |
|
| 26 |
Another case: all packages should benefit from mtimes preserving for |
| 27 |
installed files since eapi3 |
Archives