| 1 |
El vie, 05-10-2012 a las 06:31 -0400, Rich Freeman escribió: |
| 2 |
> On Fri, Oct 5, 2012 at 4:46 AM, Ulrich Mueller <ulm@g.o> wrote: |
| 3 |
> > |
| 4 |
> > I don't see any advantage in deprecating intermediate EAPIs, before we |
| 5 |
> > deprecate EAPI 0. What problem are you trying to solve? |
| 6 |
> > |
| 7 |
> |
| 8 |
> ++ |
| 9 |
> |
| 10 |
> I'm all for a policy that says to use slot deps whenever appropriate, |
| 11 |
> or to otherwise do things that actually have a real impact on the |
| 12 |
> quality/functionality of the distro. That might in practice mean |
| 13 |
> using newer EAPIs on a lot of stuff. However, I don't see the value |
| 14 |
> in bumping for its own sake. |
| 15 |
> |
| 16 |
> Legislate outcomes, not details. |
| 17 |
> |
| 18 |
> Rich |
| 19 |
> |
| 20 |
> |
| 21 |
|
| 22 |
Probably deprecating eapi1 would be interesting as probably most ebuilds |
| 23 |
would benefit from having additional src_prepare and src_configure |
| 24 |
phases. |
| 25 |
|
| 26 |
Regarding eapi4, it also has interesting changes like automatically |
| 27 |
passing --disable-dependency-tracking, they also ban dosed and dohard |
Archives