[gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'

[Duncan]

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