Deprecate EAPIs 0 and 1?
 

Hi,

after approval of EAPI 4, there are now 5 different EAPIs available,
and it's hard to remember what features are offered by which EAPI.

So maybe it's about time that we deprecate EAPIs 0 and 1 for new
ebuilds. As a first step, a warning could be added to repoman that
would be triggered whenever a new ebuild with an EAPI less than 2 is
committed.

At a later time, the warning could be changed to an error. When most
of the tree has been updated to EAPI 2 or newer, we could also think
about actively converting the remaining ebuilds. (Currently this
doesn't look feasible though, as about half of the tree is still at
EAPI=0. [1])

Opinions?

Ulrich

[1] <http://blogs.gentoo.org/alexxy/2010/11/06/some-interesting-stats-about-gentoo-portage-tree/>

Deprecate EAPIs 0 and 1?
 

On 12/31/2010 01:02 PM, Ulrich Mueller wrote:
> Hi,
>
> after approval of EAPI 4, there are now 5 different EAPIs available,
> and it's hard to remember what features are offered by which EAPI.
>
> So maybe it's about time that we deprecate EAPIs 0 and 1 for new
> ebuilds. As a first step, a warning could be added to repoman that
> would be triggered whenever a new ebuild with an EAPI less than 2 is
> committed.
>

First we need to be sure that all relevant eclasses support upgrading to
EAPI 2. As plenty of ebuilds are still in EAPI 0 it's likely that some
eclasses are too. But I do second the idea of trying to limit the set of
active EAPIs in the tree. Please open a repoman bug if there are no
objections.

> At a later time, the warning could be changed to an error. When most
> of the tree has been updated to EAPI 2 or newer, we could also think
> about actively converting the remaining ebuilds. (Currently this
> doesn't look feasible though, as about half of the tree is still at
> EAPI=0. [1])
>

EAPI 0 might stick around for quite a while but for example deprecating
EAPI 1 shouldn't be as hard.

Regards,
Petteri

Deprecate EAPIs 0 and 1?
 

On 12/31/2010 03:13 AM, Petteri Räty wrote:
> First we need to be sure that all relevant eclasses support upgrading to
> EAPI 2. As plenty of ebuilds are still in EAPI 0 it's likely that some
> eclasses are too.

As an example of things to look for, I've noticed that migration to EAPI
2 or later of any ebuild that inherits linux-mod_src_compile() will
trigger the following QA Notice from econf:

QA Notice: econf called in src_compile instead of src_configure
--
Thanks,
Zac

Deprecate EAPIs 0 and 1?
 

On 12/31/10 12:02, Ulrich Mueller wrote:
> Hi,
>
> after approval of EAPI 4, there are now 5 different EAPIs available,
> and it's hard to remember what features are offered by which EAPI.
>
> So maybe it's about time that we deprecate EAPIs 0 and 1 for new
> ebuilds. As a first step, a warning could be added to repoman that
> would be triggered whenever a new ebuild with an EAPI less than 2 is
> committed.

That's a good idea.
As long as there's a clean upgrade path from eapi0 left I'm all for it
(and that is fragile - for example bash-completion has no eapi0 versions
left, so currently it's really ugly to upgrade portage on an old install)
>
> At a later time, the warning could be changed to an error. When most
> of the tree has been updated to EAPI 2 or newer, we could also think
> about actively converting the remaining ebuilds. (Currently this
> doesn't look feasible though, as about half of the tree is still at
> EAPI=0. [1])

Since there's currently no need many ebuilds have never been upgraded.
If people started actively working on it we could get that done in a
short timeframe - but then I wonder if it's worth the effort.