On Sun, 20 Sep 2009 18:52:25 +0200
Patrick Lauer <patrick@g.o> wrote:
> > That language really should be in even if kdebuild is turned off,
> > especially if we're explicitly stating that src_test is optional.
>
> Needs to have FEATURES defined first, otherwise we'll be defining a
> specific configuration in abstract generalities. 

We use language like "at user option", without indicating what that
user option is.

> > I suggest you stop trying to push a political agenda when doing so
> > just makes life harder for the people who have to use PMS.
>
> Uhm what. I thought we had all found an agreement yesterday that
> having kdebuild in PMS was a bad thing. If you keep changing your
> opinion every day there's no way to have a reasonable discussion.

Please point me to where I (who am part of 'all') agreed that.

> > Actually, there was a perfectly clean way of doing it, and Zac even
> > agreed to do it that way before he went and implemented it
> > unconditionally. The change was supposed to be going through as
> > part of EAPI 2.
> Nah, that makes a huge stinky if you try to upgrade an EAPI0 package
> with an EAPI2 package or vice versa. Then you end up with a dozen
> potential ways of doing it, choose one randomly and hope that was a
> sane decision.
> 
> Having a consistent phase order is the only way to keep things
> predictable ...

The way that was chosen resulted in things being broken and a mad
scramble to fix things. There are at least two ways of doing it in an
entirely well defined manner that wouldn't have involved changing any
existing packages.

> > That's not how the system works. We're supposed to be documenting
> > what ebuilds may rely upon from compliant package managers. Since
> > there are compliant package managers that use both behaviours, the
> > documentation's supposed to reflect that.
> Hrm. All versions of all officially supported package managers I can
> see use the "newer" behaviour. So the "old" behaviour might be
> interesting for historical reasons, but anything currently in use is
> forced to rely on the "new" behaviour.

That's not how the system works. We don't pretend old behaviour never
existed.

> > > Feel free to document historic behaviour if you want, but as PMS
> > > hasn't documented it before I'd put it in the errata section. 
> > Doesn't PMS currently document the old way of doing it, not the new
> > way?
> See, that's what happens when you don't document what is actually
> happening.

No, it's what happens when you document what happens and then someone
goes and changes things to directly violate the specification.

> Either way there's a lot that needs to be done until PMS deserves the
> S in its name, but it's not hopeless. At least we're noticing the
> things it doesn't document or doesn't document correctly quite nicely.

Please provide examples of standards that have been retroactively
modified after publication to deal with implementations changing
behaviour.

-- 
Ciaran McCreesh