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: Maciej Mrozowski <reavertm@...>
From: Ciaran McCreesh <ciaran.mccreesh@...>
Subject: Re: Clarify wording on self-blockers
Date: Wed, 27 Apr 2011 20:24:51 +0100
On Wed, 27 Apr 2011 21:09:58 +0200
Maciej Mrozowski <reavertm@...> wrote:
> > Uh, no, that's the entire point of EAPIs.
> 
> This is a common misconception.

Uh, no. You are completely and horribly wrong.

EAPIs were introduced to avoid the problems that we used to have where
different versions of Portage did different things with the same input
(including, but not limited to, difficulties in adding new features).

> 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. 

Oh heck no. That really isn't the point at all.

From an ebuild developer's point of view, PMS describes (or at least
tries to describe -- the case under discussion here is one where PMS
probably needs fixing) what can and cannot be relied upon from the
package manager. The EAPI feature is used to restrict your ebuild's
availability to *all* package manager versions supporting a particular
set of features. Not "the most recent Portage version". *ALL* versions
of Portage that claim support for the EAPI in question.

> Old package managers and their expected behaviour is irrelevant as
> soon as migration path to recent version exists for them. 

Again, you are deeply confused. It is required that an upgrade path for
old package managers is kept around for as long as possible by not
using newer EAPIs for certain key system packages. This is entirely
different to what you're saying -- it means that certain packages
should be kept at low EAPIs for as long as possible, not that EAPIs are
whatever the latest Portage version does.

> 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.

That doesn't follow at all. What happens if someone has an old Portage
installed and the migration path includes things that rely upon a
changed behaviour? Since you're trying to retroactively define a
particular behaviour for all EAPIs that doesn't match what some old
Portage versions do, your upgrade path is screwed.

This sort of thing really should be in the developer quiz. It's too
basic and fundamental for people to be getting wrong.

-- 
Ciaran McCreesh
Attachment:
signature.asc (PGP signature)
Replies:
Re: Clarify wording on self-blockers
-- Maciej Mrozowski
References:
Clarify wording on self-blockers
-- Ulrich Mueller
Re: Clarify wording on self-blockers
-- Maciej Mrozowski
Re: Clarify wording on self-blockers
-- Ciaran McCreesh
Re: Clarify wording on self-blockers
-- Maciej Mrozowski
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.