Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-pms
Navigation:
Lists: gentoo-pms: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-pms@g.o
From: Maciej Mrozowski <reavertm@...>
Subject: Re: Clarify wording on self-blockers
Date: Wed, 27 Apr 2011 21:09:58 +0200
On Wednesday 27 of April 2011 19:46:21 Ciaran McCreesh wrote:
> On Wed, 27 Apr 2011 19:40:47 +0200

> Maciej Mrozowski <reavertm@...> 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
Attachment:
signature.asc (This is a digitally signed message part.)
Replies:
Re: Clarify wording on self-blockers
-- Ciaran McCreesh
References:
Clarify wording on self-blockers
-- Ulrich Mueller
Re: Clarify wording on self-blockers
-- Maciej Mrozowski
Re: Clarify wording on self-blockers
-- Ciaran McCreesh
Navigation:
Lists: gentoo-pms: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: Clarify wording on self-blockers
Next by thread:
Re: Clarify wording on self-blockers
Previous by date:
Re: Clarify wording on self-blockers
Next by date:
Re: Clarify wording on self-blockers


Updated Jul 18, 2012

Summary: Archive of the gentoo-pms mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.