On Fri, Aug 31, 2012 at 03:49:43PM +0100, Ciaran McCreesh wrote: > On Thu, 30 Aug 2012 23:58:00 +0000 (UTC) > Duncan <1i5t5.dun...@cox.net> wrote: > > Of course an individual PM could choose to keep support for as long > > as they want, but unless I'm missing something, that'd let PMs drop > > support for old EAPIs if desired, with at least a reasonably sane > > upgrade path for both PM devs and users. > > It's irrelevant: the amount of package mangler code to be saved by > removing old EAPIs is so small it's not worth discussing. Most EAPI > changes so far have either been additions or very simple behaviour > tweaks, not removals of annoying things.
Just seconding this statement; no PM author has stated "maintaining EAPIs is an undue burden"- it's come everytime from folks who don't /actually do any PM code/. So please stop telling us what is, and isn't a burden in our code. :) > There are things we might change in future EAPIs that will in the very > long term make this discussion worthwhile. If we get rid of VDB access > or unconstrained env saving, *then* it might be worth having this > discussion. Realistically even then, that's just swivelling vars/functions exposed to the ebuild env- it would require the vast majority of ebuilds migrating to EAPI versions that hide VDB access for this to be worth discussing (else due to backwards compat, it's a pointless discussion). Either way, there's no reason to require devs use the latest EAPI; they migrate at their own pace as they need to, which is fine. Case in point, check gentoo-x86 eapi usage: repository '/var/db/repos/gentoo': eapi: '4' 13523 pkgs found, 42.58% of the repository eapi: '0' 8171 pkgs found, 25.73% of the repository eapi: '2' 5246 pkgs found, 16.52% of the repository eapi: '3' 4297 pkgs found, 13.53% of the repository eapi: '1' 520 pkgs found, 1.64% of the repository 0 is still in heavy usage since a lot of ebuilds don't need the newer EAPI functionality; 1 is mostly dead since the only gain of it (in comparison to 0) was slot deps, 2 had used use deps thus those same folk migrated to 2 (since if you need slot deps, it's semi likely you need use deps). As for 3... that was prefix and xz support. No reason to use it in comparison to 4 frankly. Personally, I don't have any problems if gentoo were to mandate that EAPI1 shouldn't be used for new ebuilds in gentoo-x86, eapi2 instead. That sort of standard would make sense. ~harring
