On Sat, 21 Mar 2009 18:37:12 +0100 Patrick Lauer <patr...@gentoo.org> wrote:
> To make our lives easier I would suggest deprecating EAPI0 and > migrating existing ebuilds over some time to EAPI1 or higher until > EAPI0 can be obsoleted at some point in the future. > I would set the start of deprecation warnings about 3 months from now > and the obsoletion quite a time later, maybe 12 months from now, when > a sufficient amount of ebuilds has been migrated. As always, wording is important. I think having too many EAPIs in active use unnecessarily complicates things, such as remembering which features are offered by which EAPIs, etc. I think we should start deprecating EAPI=0 usage *now* with a repoman warning whenever a new ebuild is committed that does not use EAPI=1 or EAPI=2. This warning should encourage use of the newest EAPI, EAPI=2. Obsoleting EAPI=0 should occur when the decision to do so merely codifies the state of the tree (at 90% EAPI>0, to pick a number ), at which point the warning would be changed to an error. We could then use a couple of bugdays to convert the remainder of the ebuilds or hand them over to treecleaners if it's just unmaintained cruft. In a year or so, we could change the repoman warning to trigger with EAPI=1 also and make it point to EAPI=3 as the EAPI-of-choice. > Deprecating EAPI1 at the same time would reduce the amount of EAPIs > we have to think about, but since it has some changes like adding > src_prepare migration would not be as trivial. So I'd prefer keeping > it around a bit longer. > > Comments? We need to make this a part of the EAPI-upgrade process that whenever a new EAPI is added, we consider including another EAPI in the repoman warning. My hope is that at some point in the future (4 years?), we'll be able to cut out some of the ugly phase hacks we have in many eclasses that had EAPI=2 grafted onto them. /loki_val
