On Mon, 10 Feb 2014 17:05:22 +0100 Ulrich Mueller <u...@gentoo.org> wrote:
> >>>>> On Mon, 10 Feb 2014, Rich Freeman wrote: > > > On Mon, Feb 10, 2014 at 10:31 AM, Ulrich Mueller <u...@gentoo.org> > > 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 : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
signature.asc
Description: PGP signature
