On Thu, 22 Feb 2007 17:10:38 +0100 Marien Zwart <[EMAIL PROTECTED]> 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. -- [email protected] mailing list
