RFC: Deprecating EAPI0
 

Hi all,

with the discussion about EAPI3 we have now 4 (or 7, depending on how you
count them ;) ) EAPIs available or almost available. This is getting quite
confusing.
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.

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?


Patrick

RFC: Deprecating EAPI0
 

On Sat, Mar 21, 2009 at 10:37 AM, Patrick Lauer <patrick@gentoo.org> wrote:
> Hi all,
>
> with the discussion about EAPI3 we have now 4 (or 7, depending on how you
> count them ;) ) EAPIs available or almost available. This is getting quite
> confusing.

Be more specific, what actual problems have you encountered?
What are some other ways we could mitigate these issues (it seems like
tool improvements could be a big one here)?

> 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.

I am interested in the number of ebuilds at specific APIs in the tree,
do you have those numbers?
Basically, how much work is this (raw ebuild count)?

>
> 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?
>
>
> Patrick
>
>

RFC: Deprecating EAPI0
 

Alec Warner schrieb am 21.03.2009 20:45:


Be more specific, what actual problems have you encountered?
What are some other ways we could mitigate these issues (it seems like
tool improvements could be a big one here)?



Regarding the depreciation of EAPI's I think eclasses will probably
benefit from a low number of possible EAPI's. I am thinking about the
introduction of more and more EAPI's which all need to be considered in
the eclasses which will get tedious.


Regards,

Daniel

RFC: Deprecating EAPI0
 

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

Uh. Why?

Introducing a policy encouraging moving things that definitely aren't
in the least bit likely to be a system dep on a bump, sure. Making 1 or
2 the default for new packages, sure. But rewriting existing things?
That's just an accident waiting to happen.

--
Ciaran McCreesh

RFC: Deprecating EAPI0
 

On Saturday 21 March 2009 19:37:12 Patrick Lauer wrote:
> Hi all,
>
> with the discussion about EAPI3 we have now 4 (or 7, depending on how you
> count them ;) ) EAPIs available or almost available. This is getting quite
> confusing.
> 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.
>
> 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?
>
>
> Patrick
The gain obtained by this migration doesnt compensate for the efford/work one
(we) must put into this. But if we decide to mark EAPI0 as deprecated, first it
would be nice to have a tree cleanup cause it doesn't make much sense to
migrate broken/unmaintained/old/etc ebuilds onto newer EAPIs.

--
Markos Chandras (hwoarang)
Gentoo Linux Developer
KDE/Qt/Sunrise/Sound
Web: http://hwoarang.silverarrow.gr

RFC: Deprecating EAPI0
 

Alec Warner wrote:
> I am interested in the number of ebuilds at specific APIs in the tree,
> do you have those numbers?
> Basically, how much work is this (raw ebuild count)?
>
Total ebuilds 26209
EAPI0 ebuilds 22880
EAPI1 ebuilds 1855
EAPI2 ebuilds 1474

this numbers based on regexps =)

--
Alexey 'Alexxy' Shvetsov
Gentoo/KDE
Gentoo/MIPS
Gentoo/SCI
Gentoo Team Ru

RFC: Deprecating EAPI0
 

On Saturday 21 March 2009 21:21:47 Ciaran McCreesh wrote:
> On Sat, 21 Mar 2009 18:37:12 +0100
>
> Patrick Lauer <patrick@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.
>
> Uh. Why?
Because, as you have noticed before, developers get confused which eapi has
which features available. And eapi1 is a superset of eapi0, so we don't have
to rewrite tons of things.

> Introducing a policy encouraging moving things that definitely aren't
> in the least bit likely to be a system dep on a bump, sure. Making 1 or
> 2 the default for new packages, sure. But rewriting existing things?
> That's just an accident waiting to happen.
What kind of accident do you expect to happen?

Patrick

RFC: Deprecating EAPI0
 

On Sat, 21 Mar 2009 21:53:16 +0100
Patrick Lauer <patrick@gentoo.org> wrote:
> Because, as you have noticed before, developers get confused which
> eapi has which features available. And eapi1 is a superset of eapi0,
> so we don't have to rewrite tons of things.

So? When people do new things, they can move the EAPI forward. That's
not a reason to modify existing things.

> > Introducing a policy encouraging moving things that definitely
> > aren't in the least bit likely to be a system dep on a bump, sure.
> > Making 1 or 2 the default for new packages, sure. But rewriting
> > existing things? That's just an accident waiting to happen.
>
> What kind of accident do you expect to happen?

The same kind that always happens when lots of ebuilds get changed.

--
Ciaran McCreesh

RFC: Deprecating EAPI0
 

Alexey Shvetsov wrote:

Alec Warner wrote:

I am interested in the number of ebuilds at specific APIs in the tree,
do you have those numbers?
Basically, how much work is this (raw ebuild count)?


Total ebuilds 26209
EAPI0 ebuilds 22880
EAPI1 ebuilds 1855
EAPI2 ebuilds 1474

this numbers based on regexps =)



With these numbers, I don't exactly see the point of deprecating EAPI0.
Too much work that we could be spending elsewhere.. Although, I suppose
someone will propose to make the "default EAPI" be 1 instead of 0. I
don't see a point for that either.


-Jeremy

RFC: Deprecating EAPI0
 

On Saturday 21 March 2009 21:55:20 Ciaran McCreesh wrote:
> On Sat, 21 Mar 2009 21:53:16 +0100
>
> Patrick Lauer <patrick@gentoo.org> wrote:
> > Because, as you have noticed before, developers get confused which
> > eapi has which features available. And eapi1 is a superset of eapi0,
> > so we don't have to rewrite tons of things.
>
> So? When people do new things, they can move the EAPI forward. That's
> not a reason to modify existing things.

The added complexity of having a dozen eapis does not offer any benefits to
the average developer. Limiting the amount of complexity tends to reduce the
amount of errors, be it simple developer mistakes or unexpected interaction
errors between different EAPIs in the package manager.

> > > Introducing a policy encouraging moving things that definitely
> > > aren't in the least bit likely to be a system dep on a bump, sure.
> > > Making 1 or 2 the default for new packages, sure. But rewriting
> > > existing things? That's just an accident waiting to happen.
> >
> > What kind of accident do you expect to happen?
>
> The same kind that always happens when lots of ebuilds get changed.

... lots of new features and a few bugs that get fixed the next day? Hey, that
sounds quite bad. And maybe some new herd testers? How rude!

So what technical reason(s) do we have to keep archaic EAPIs around forever?

Patrick