Drop EAPI=0 requirement for system packages.
 

From time to time the topic of deprecating EAPIs comes up and usually
one suggestion is to keep 0 and start with converting EAPI 1 ebuilds.
Then someone comes along and asks what is the point? Indeed, a fair
question.

The following tries to take a different approach to the topic. It's not
all thought through in detail, but that wont happen anytime soon,
after all it's on my TODO for long enough. So I present it in the hope
others will try to poke holes into it or even pick it up.


EAPI=0 requirement pointless?
-----------------------------

The EAPI=0 requirement comes from having to provide an update path for
systems with a package manager without EAPI support. By now we are
talking about really ancient systems and it's questionable if there is
any merit in supporting such.

Further the situation is that some of the maintainers of must be EAPI 0
ebuilds already moved on as the majority of users will profit from a
bump. As a result the clean upgrade path is already borked and the
value of keeping others at EAPI=0 deteriorates further and further.

Forcing EAPI 0 on some maintainers for all eternity doesn't strike me
as brilliant, quite the opposite frankly. After all new EAPIs are
supposed to contain bug fixes and new features required to write better
ebuilds.


If all installed PMs supported EAPI?
------------------------------------

The issue of an update path is reduced to keeping intermediate
versions in tree.

Those PMs also support EAPI=1, rendering EAPI=0 obsolete.


Base EAPI
---------

Systems without having a package manager installed that supports at
least the 'Base EAPI' aren't considered supported any longer.

Maintainers of system packages can use the Base EAPI without worrying.

Maintainers of system packages can use more recent EAPIs but need to
take special care.


Value of Base EAPI
------------------

Maintainers of system packages need to be able to use newer EAPIs
after some time. They can wait but not forever. built_with_use removal
is one example, strong vs weak blockers an other.

The value can be based on time ( i.e. after 3 years ) or set by council
decision. A combination is fine as well.

The value should be kept low enough so the rule "maintainers don't have
to care about using it" holds.

The need of derived distributions / package managers should be
considered, ie. let them catch up if necessary.

Security updates should be possible for some time without full updates.
This extends to other packages as well. So maintainers of critical non
system packages can use this EAPI as well if they want.

Guess EAPI=2 would be a reasonable compromiss.


Deprecation?
------------

EAPIs below the base EAPI can be considered deprecated if one desires.

References in devmanual can be removed and so the document be
simplified.

Once there are only few ebuild of a deprecated EAPI left, it might make
sense to convert them and add a repoman check so the number of used
EAPIs is kept reasonable.

Drop EAPI=0 requirement for system packages.
 

On Fri, Oct 12, 2012 at 12:53:15PM +0200, Ralph Sennhauser wrote
> From time to time the topic of deprecating EAPIs comes up and usually
> one suggestion is to keep 0 and start with converting EAPI 1 ebuilds.
> Then someone comes along and asks what is the point? Indeed, a fair
> question.

It's my understanding that higher EAPI levels include more features.
How backwards compatable are the EAPI levels? I.e. assume that we take
an ebuild with EAPI 0, and slap in EAPI=1 (or 2 or 3, etc) at the top,
without any other changes. Are there any circumstances where the ebuild
would behave differently and/or break?

The current default, if EAPI is not specified, is EAPI 0. What I'm
getting at is... can we safely tell portage to assume that all ebuilds
with no EAPI declaration are EAPI 1 (or 2 or 3, etc)? Or will that
break some ebuilds? Actually, if only a small percentage of ebuilds
break, then it might not be too much of an effort to fix that small
subset.

--
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Drop EAPI=0 requirement for system packages.
 

On Fri, 12 Oct 2012 16:38:06 -0400
"Walter Dnes" <waltdnes@waltdnes.org> wrote:
> On Fri, Oct 12, 2012 at 12:53:15PM +0200, Ralph Sennhauser wrote
> > From time to time the topic of deprecating EAPIs comes up and
> > usually one suggestion is to keep 0 and start with converting EAPI
> > 1 ebuilds. Then someone comes along and asks what is the point?
> > Indeed, a fair question.
>
> It's my understanding that higher EAPI levels include more features.
> How backwards compatable are the EAPI levels? I.e. assume that we
> take an ebuild with EAPI 0, and slap in EAPI=1 (or 2 or 3, etc) at
> the top, without any other changes. Are there any circumstances
> where the ebuild would behave differently and/or break?

In EAPIs after 1, as well as adding shiny new toys, we've removed
various deprecated things, split up phase functions, and made some
helpers error on invalid input.

--
Ciaran McCreesh

Drop EAPI=0 requirement for system packages.
 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 12/10/12 04:38 PM, Walter Dnes wrote:
> On Fri, Oct 12, 2012 at 12:53:15PM +0200, Ralph Sennhauser wrote
>> From time to time the topic of deprecating EAPIs comes up and
>> usually one suggestion is to keep 0 and start with converting
>> EAPI 1 ebuilds. Then someone comes along and asks what is the
>> point? Indeed, a fair question.
>
> It's my understanding that higher EAPI levels include more
> features. How backwards compatable are the EAPI levels? I.e.
> assume that we take an ebuild with EAPI 0, and slap in EAPI=1 (or 2
> or 3, etc) at the top, without any other changes. Are there any
> circumstances where the ebuild would behave differently and/or
> break?

Yes. There is more than just new features that have been added. Some
default operations have changed. Eclass behaviour can also be different.

I'll let others go into the details, but one of the big changes
between EAPIs is the way an unspecified DEPEND or RDEPEND is handled.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlB4gVYACgkQ2ugaI38ACPB45QD+PC6PvspnXd mOhMAEOIDPxh2m
4RDWrTw8t86O+iyKodsA/RdRo1r1Xxc734hXbAwtZlxjC3KcU/mnGQVysvflOdjW
=uk9m
-----END PGP SIGNATURE-----

Drop EAPI=0 requirement for system packages.
 

On Fri, 2012-10-12 at 16:38 -0400, Walter Dnes wrote:
> It's my understanding that higher EAPI levels include more features.
> How backwards compatable are the EAPI levels? I.e. assume that we take
> an ebuild with EAPI 0, and slap in EAPI=1 (or 2 or 3, etc) at the top,
> without any other changes. Are there any circumstances where the ebuild
> would behave differently and/or break?

See http://devmanual.gentoo.org/ebuild-writing/eapi/index.html

Updating an ebuild from EAPI0 to EAPI1 without changes should be safe.

Updating from EAPI0 to EAPI2 or higher without changes is not safe; at
the minimum, econf calls would need to be moved from src_compile to
src_configure.

Drop EAPI=0 requirement for system packages.
 

On Fri, 12 Oct 2012 12:53:15 +0200
Ralph Sennhauser <sera@gentoo.org> wrote:

> The EAPI=0 requirement comes from having to provide an update path for
> systems with a package manager without EAPI support. By now we are
> talking about really ancient systems and it's questionable if there is
> any merit in supporting such.
>
> Further the situation is that some of the maintainers of must be EAPI 0
> ebuilds already moved on as the majority of users will profit from a
> bump. As a result the clean upgrade path is already borked and the
> value of keeping others at EAPI=0 deteriorates further and further.

Yeah as soon as python went it was pretty much pointless. I don't see any
value in forcing system packages to EAPI 0 anymore. Everything you're saying
makes sense to me at least.

I'd argue against deprecating EAPI 0 any time soon though. Killing EAPI 1
would be a better idea.


--
gcc-porting
toolchain, wxwidgets we were never more here, expanse getting broader
@ gentoo.org but bigger boats been done by less water

Drop EAPI=0 requirement for system packages.
 

On Fri, 12 Oct 2012 21:10:23 -0600
Ryan Hill <dirtyepic@gentoo.org> wrote:

> I'd argue against deprecating EAPI 0 any time soon though. Killing
> EAPI 1 would be a better idea.

I'm not for forced EAPI bumps anytime soon, but I expect EAPI 0 to be
gone from tree in 3-5 years once the EAPI=0 requirement is lifted.

Currently we have only 6 official EAPIs which is still manageable to
remember the details of each. Though it might be confusing for new
developers. Once we are at 20 EAPIs it will be an issue also for
seasoned folks.

Therefore deprecation is a given, how to go about it is certainly up to
discussion. What do you see as an acceptable path here?