| 1 |
On 5 October 2012 06:31, Rich Freeman <rich0@g.o> wrote: |
| 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 |
I don't think deprecating EAPIs for new ebuilds is a good/useful |
| 22 |
thing. Sure the new EAPIs are nice and all, but if the package works |
| 23 |
fine with an older EAPI and there's no need to use the features of a |
| 24 |
newer one, why not leave it? |
| 25 |
|
| 26 |
In some cases, EAPI bumps are detrimental to users on old systems that |
| 27 |
have a older portage because they wind up being blocked by stuff like |
| 28 |
new portage requiring new python which requires pkgconfig and all |
| 29 |
pkgconfig ebuilds are EAPI=4 so you're stuck. |
Archives