| 1 |
On Wed, Oct 17, 2012 at 1:34 PM, Pacho Ramos <pacho@g.o> wrote: |
| 2 |
> Would be easier to prune old versions if we "force" them to be less |
| 3 |
> using at least preventing new ebuilds to use them. For example, what is |
| 4 |
> the advantage for a new ebuild to still rely on old src_compile phase |
| 5 |
> instead of src_prepare/configure...? |
| 6 |
|
| 7 |
It can be bumped by copying it from the ebuild for the previous |
| 8 |
version, thus introducing no errors. Or maybe the person who authored |
| 9 |
it (who might or might not even be a developer) isn't familiar with |
| 10 |
the latest EAPI, but the code still works. |
| 11 |
|
| 12 |
A policy that says all new ebuilds shall use EAPI foo might result in |
| 13 |
fewer new ebuilds. Sure, they'll have new and shiny fooness, but |
| 14 |
arguably I'd rather have more packages supported on older EAPIs then |
| 15 |
fewer packages supported on newer ones. |
| 16 |
|
| 17 |
Again, as I stated before, things that actually benefit the end users |
| 18 |
like slot dependencies are fine to mandate when it makes sense to do |
| 19 |
so. |
| 20 |
|
| 21 |
I think the whole developers-can't-handle-47-EAPIs thing is a red |
| 22 |
herring. The fact that there are packages written in Erlang in the |
| 23 |
tree doesn't cause me any issues even though I haven't had to do any |
| 24 |
work in Erlang. If I ever wanted to maintain such a package then I'd |
| 25 |
take the time to learn it as needed. Likewise, if I wanted to |
| 26 |
maintain a package that used EAPI joe and I really prefer to work in |
| 27 |
EAPI fred, then I'd revise it at my next convenience. |
| 28 |
|
| 29 |
Rich |
Archives