Robert Buchholz posted on Sat, 22 Aug 2009 01:44:51 +0200 as excerpted: > I wonder what the value of the PMS specification is if every time an > inconsistency comes up the argument is raised that it should document > portage behavior. EAPI 1, 2 and 3 have been agreed by the council and > PMS is in a stage where Portage should obey its definitions and not the > other way around.
> Trying to ignore the fact this standard exists is a way to breakage. There are, as I see it, two issues here. 1) This feature can be reasonably argued to have fallen thru the cracks, since it was actually implemented before PMS. Yes, the committing documentation said it was for user config only, but the implementation was in general, and in general, EAPI-0 was to document existing behavior, so we have a problem. It's thus one of a very limited number of candidates, and it's not like there's going to be hundreds more where this came from. 2) If I'm not mistaken, EAPI-0 has never been fully finalized anyway. It has gotten to preliminary approval, where bugs are supposed to be filed where there's a conflict, and a resolution worked out. All other approved EAPIs have been defined as differences from previous versions, but due to the way EAPI-0 came about, nobody has really been sure enough it's 100% defined, and final approval hasn't happened as a result. Given that this feature was there before PMS. despite what the documentation actually said, it's precisely the type of bug that was intended to be covered by the preliminary approval, and hammering it out as that preliminary approval outlined is where we're at right now. If #2 is indeed correct, then we don't have a loophole, we have a legitimate bug that's we're in the process of hashing out, and it's not at all clear cut whether the bug is in portage and arguably the original documentation or in PMS. That's a matter of viewpoint that will likely take a council vote to solve. However, as I pointed out on the bug, either way it's not particularly difficult to solve it. Should council decide to run with the existing portage behavior, since it has been there for years, the old pre-PMS wait- a-year before changes can be allowed in tree need not apply. I suggested 30-90 days before it's allowed in official overlays, and 90-180 days before it's allowed in-tree, altho using it only in the new profiles works too. If it goes the other way, then as Zac points out, it's a simple matter to change the portage documentation once again, and since it's not in-tree yet (well, at least before the new-profile announcement, and anything that new and limited to them can be reverted fairly easily too), not a big deal. It can then wait for EAPI-4 But regardless, it /does/ appear it'll take a council vote on this, one way or the other. The matter has been requested for the next council meeting. I'd hope everybody can agree to just slow down a bit until then. (Zac just committed a portage documentation note mentioning it's not in PMS yet, and no intervening releases have been made with the questioned wording /without/ that clause, AFAIK, so that end's covered.) If at that point it's postponed, that too is effectively a decision, but I should hope it won't be postponed, as it's relatively simple either way, and we need a resolution from council, as the authoritative body designated to resolve such issues, both in general, and if I'm not mistaken, in the preliminary EAPI-0 approval. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
