Gentoo Archives: gentoo-pms

From: Maciej Mrozowski <reavertm@×××××.com>
To: gentoo-pms@l.g.o
Subject: Re: [gentoo-pms] Clarify wording on self-blockers
Date: Wed, 27 Apr 2011 19:10:16
Message-Id: 201104272109.59259.reavertm@gmail.com
In Reply to: Re: [gentoo-pms] Clarify wording on self-blockers by Ciaran McCreesh
On Wednesday 27 of April 2011 19:46:21 Ciaran McCreesh wrote:
> On Wed, 27 Apr 2011 19:40:47 +0200
> Maciej Mrozowski <reavertm@×××××.com> wrote: > > I'd say using "in some ancient portage" argument all over again to > > reinforce particular point of view is not valid. > > Uh, no, that's the entire point of EAPIs.
This is a common misconception. The entire and only point of EAPI is to provide ebuild API - for ebuild developers and for package manager developers. From user point of view - user is required to update package manager (it's the case with portage anyway) to the latest supported version and package manager itself (along with package tree) needs to support such migration path (of course within reasonable timespan - there is catch whether pre-EAPI-2 support is reasonable, python eclass problem). From ebuild developer point of view - EAPI specification should provide all knowledge required to create ebuilds along with detailed and unambiguous description of what to expect from package manager that is compliant with said EAPI. Old package managers and their expected behaviour is irrelevant as soon as migration path to recent version exists for them. That being said this argument blocking the update of specification because of the hypothetical existence of unsupported package manager instances (like ancient portage/paludis/pkgcore versions) is invalid. From package manager developer point of view - EAPI specification should provide all knowledge required to build own package manager compliant with said EAPI, describing its *intended* (and of course being in effect, not just intended) behaviour in detailed and unambiguous way. And here again, old package managers and their provided behaviour is irrelevant as soon as migration path exists for them. Since intended behaviour for normal vs strong blocks is like Ulrich specified, and migration path to the most recent from first portage supporting EAPI-2 exists - argument to block specification update is invalid. EAPI specification is not "what used to be", it's "what is and what can be relied upon", it's that simple. -- regards MM

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies

Subject Author
Re: [gentoo-pms] Clarify wording on self-blockers Ciaran McCreesh <ciaran.mccreesh@××××××××××.com>