Re: [gentoo-dev] [RFC] Tightening EAPI rules

[Tom Wijsman]

On Mon, 10 Feb 2014 17:05:22 +0100
Ulrich Mueller <ulm@g.o> wrote:

> >>>>> On Mon, 10 Feb 2014, Rich Freeman wrote:
>
> > On Mon, Feb 10, 2014 at 10:31 AM, Ulrich Mueller <ulm@g.o>
> > wrote:
> >> I'd rather argue in terms of time instead of version numbers,
> >> because of the upgrade path for old systems. We guarantee one year
> >> for stable systems, but IMHO we should be more conservative for
> >> EAPI deprecation and go for two or three years there.
>
> > By EAPI deprecation it is meant that we discourage using the old
> > EAPI in the tree.
>
> Right, the above was about ebuilds in the tree, not about package
> managers. At least sys-apps/portage and its dependencies must stay at
> an EAPI that is stable long enough to allow an upgrade of old systems
> (where Portage might not recognise the newest EAPI).

Yes, besides the way we deprecate it we should also be clear in our
wording what this all pertains to; a broad statement can has its effect
in the Portage tree, the package manager, the upgrade path, the vdb and
possibly more. Otherwise we get what Patrick describes; a warning in
repoman, with nearly no progress wrt its removal in the Portage tree.

> > Removing support for it from a package manager should of course
> > happen much later (well after it is banned).
>
> The package manager must be able to uninstall old packages, which
> essentially means that support for old EAPIs cannot be removed.

That's only a subset of the entire EAPI, which could be separately
still supported; while no longer supporting the majority of it, for
example, whether src_prepare is supported doesn't really matter anymore
when you are uninstalling a package. One could make up a list; however,
it's not a problem yet, it might become one in 10 years or so...

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@g.o
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D