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