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
While there definitely arguments for deprecating EAPIs, I would suggest
caution.
A low number of active EAPIs can make life easier for developers, but it
can also make life harder for some users. There are still users coming
to the forums upgrading systems which only understand EAPI 0. I accept
that Gentoo is certainly a relatively fast moving distro, but I think
that developers also do need to consider users who have systems that are
currently "just working" and may not upgrade often (once a year or even
less).
As such, I would suggest that forcing a move to the most recent stable
EAPI is possibly unwise.
I believe that forcing EAPIs to move forward at too quick a pace will
cause more issues for these users. An answer to this could be to set a
standard for the minimum time between upgrades - for example, 1 year -
and ensure that users with anything that old can atleast upgrade portage
and its dependencies to the minimum required versions without major issues.
I understand that this may cause extra work in some respects, but if
such a standard is set and documented then it will help users (admins)
by giving them a set frequency at which they must upgrade at least the
package manager, if not @system.
Secondly, it was suggested that a project to upgrade all ebuilds in the
tree from EAPI 0 could bring new developers, offering KDE4 as an
example. I would offer caution on this assumption. KDE4 was not simply
about upgrading ebuilds, but about users (contributors) and developers
being able to install and test packages they wanted to install and test.
I can not realistically see such an effort being asserted in the name of
simply deprecating EAPIs.
Yes, breakage occurred, but this was as far as I can see a complete
rewrite of the KDE packaging from scratch. As such I would suggest that
a certain level of breakage was to be expected. I would also suggest
that the speed at which bugs are being fixed may be more of an indicator
of lack of man power than anything else, and that the situation could be
improved by looking at expending more effort on encouraging
contributions and ultimately recruiting developers. I realize that
getting people to expend effort on non-coding work can be difficult, but
I think that ultimately the effort expended will be repaid in terms of
extra contributions.
In general, I would have to agree with those who believe there are
currently better ways to expend effort within Gentoo. As such I would
suggest that at most, EAPI deprecation only applies to new packages and
version bumps.
AllenJB
