Gentoo Archives: gentoo-pms

From: Ciaran McCreesh <ciaran.mccreesh@××××××××××.com>
To: Patrick Lauer <patrick@g.o>
Cc: gentoo-pms@l.g.o
Subject: Re: [gentoo-pms] Small cleanup of ebuild-functions.tex
Date: Sun, 20 Sep 2009 17:02:18
Message-Id: 20090920180153.6df4b022@snowcone
In Reply to: Re: [gentoo-pms] Small cleanup of ebuild-functions.tex by Patrick Lauer
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

Attachments

File name MIME type
signature.asc application/pgp-signature