We'd like to drop perl-5.16's now useless build USE flag. In order to do so, we must update perl-module.eclass's dependency: > DEPEND="dev-lang/perl[-build]" to > DEPEND="dev-lang/perl[-build(-)]" which is an EAPI=4 feature. There are 1377 packages inheriting perl-module.eclass, with an EAPI usage breakdown of: > Overall statistic for eclass "perl-module.eclass": > EAPI=unsupported count: 0 > EAPI=0 count: 157 > EAPI=1 count: 3 > EAPI=2 count: 146 > EAPI=3 count: 163 > EAPI=4 count: 1530 > EAPI=5 count: 236 So, 469 packages to update to EAPI >= 4. This will be a tracker, but since I imagine that many of the packages that need to be ported are in the perl herd, we won't need separate bugs for them all.
Created attachment 354566 [details] EAPI=0 packages inheriting perl-modules
Created attachment 354568 [details] EAPI=1 packages inheriting perl-modules
Created attachment 354570 [details] EAPI=2 packages inheriting perl-modules
Created attachment 354572 [details] EAPI=3 packages inheriting perl-modules
I've updated the dependency from > dev-lang/perl[-build] to > || ( >=dev-lang/perl-5.16 <dev-lang/perl-5.16[-build] ) to work-around the problem for now and let us drop the build flag from >=perl-5.16. We should still update packages inheriting the perl-module eclass to newer EAPIs.
Created attachment 357524 [details] EAPI=0 packages inheriting perl-modules
Created attachment 357526 [details] EAPI=1 packages inheriting perl-modules
Created attachment 357528 [details] EAPI=2 packages inheriting perl-modules
Created attachment 357530 [details] EAPI=3 packages inheriting perl-modules
After one month, before -> after: > EAPI=0 count: 157 -> 62 > EAPI=1 count: 3 -> 1 > EAPI=2 count: 146 -> 51 > EAPI=3 count: 163 -> 59 > EAPI=4 count: 1530 -> 1404 > EAPI=5 count: 236 -> 271 So, 469 -> 173 packages left. :)
Comment on attachment 357526 [details] EAPI=1 packages inheriting perl-modules >app-arch/alien-8.87
EAPI=1 list is over.
(In reply to Mikle Kolyada from comment #12) > EAPI=1 list is over. so too the rest
Created attachment 370040 [details] EAPI=3 list Updated list with EAPI=3 packages.
Created attachment 370042 [details] EAPI=2 list Updated EAPI=2 list
Created attachment 370050 [details] EAPI=3 list A bit updated list (reformated as CAT/${p}) for EAPI=2
Created attachment 370052 [details] EAPI=3 list A bit updated list (reformated as CAT/${p}) for EAPI=3
Created attachment 370054 [details] EAPI=2 list Yet another update to package list. EAPI=2
Created attachment 370056 [details] EAPI=3 list Yet another update to package list. EAPI=3.
Created attachment 370058 [details] EAPI=0 list EAPI=0 list.
Created attachment 379914 [details] old_eapi_list New old EAPI list.
Created attachment 379916 [details] old_eapi_list Oops, forgot to exclude all non-ebuild things.
See ${URL} for new list now.
All done, waiting for eclass changes.
01 Nov 2014; Andreas K. Huettel <dilfridge@gentoo.org> perl-module.eclass: Drop EAPI=0,1,2,3 support in perl-module.eclass, this time for real. Further cleanups will follow.
I propose there are two open issues with this bug triggering a third 1) Somthing about the way the build flag was removed creates a slot conflict when users updating pull in a newer perl. The slot conflict will cause the update to break 100% of the time and all users have to go manually in the dark. 2) The way portage perl (eclass?) dropped support for EAPI2 on Nov 1st does so without converting or checking ebuilds in users g-cpan overlays. g-cpan which used EAPI2 is heavally used now that so many perl modules are being not supported by Gentoo. There is no path for g-cpan users to deal with the dropping of EAPI < 4 once again in the dark. 3)Due to the above there seems to be no clear way to update perl with out having to resort to manually removing all g-cpan modules, unmerging all perl packages then re-emerging them. This update process is manual, complex, involved and not documented. Somthing of this scale should have some kind of guide or at least a news item. Pardon my spam if I missed any of the aforementioned.