Re: [gentoo-dev] Re: EAPI spec (was Re: Re: let's clear things up (was Slacker archs))

[Stephen Bennett]

On Thu, 22 Feb 2007 17:10:38 +0100
Marien Zwart <marienz@g.o> wrote:

> I am a bit unsure about what the goal for PMS is here. It does not
> seem to be to document what a certain (the current?) version of
> portage does, as the defacto standard. Instead you want to document
> what portages *intention* is, or something like that. That obviously
> sounds like an excellent idea, but as far as I know most of the PMS
> contributors are also Paludis devs. Paludis, being an alternative to
> portage, is *also* trying to handle ebuilds the way portage is
> "intended" to handle them. So what I'm afraid of is that "by the time
> that Paludis 1.0_pre is released" we will simultaneously see PMS
> released to the public, and Paludis 1.0_pre supporting that PMS
> perfectly, with all deviations on the part of portage (or pkgcore)
> being considered "bugs" in their implementation of the specification.

The intention is much as you initially surmised -- to describe
portage's intended behaviour, or perhaps more accurately that subset of
Portage's current behaviour which ebuilds and eclasses upon which are
allowed to rely. Certainly by the time it is finished and sent to the
Council for approval I expect whatever is the current Portage release
to be compatible, and in most cases where I've deviated thus far from
what Portage allows or does I've asked the current portage team whether
it seems reasonable to do so.

In some cases there are ebuilds in the tree relying upon behaviour that
is not specified by PMS, or intended to be. These are the cases where
only one or two packages rely upon undocumented and often unintentional
by-products of Portage behaviour, and it seems more sensible to fix
those few ebuilds instead of adding a lot of compatibility junk to the
standard. A good example of this would be the recent -dev thread on
global ebuild variables and pkg_setup.
-- 
gentoo-dev@g.o mailing list