Re: [gentoo-dev] RFC: Deprecating EAPI0

[Peter Alfredsen]

On Sat, 21 Mar 2009 18:37:12 +0100
Patrick Lauer <patrick@g.o> 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