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

[Paul de Vrieze <pauldv@gentoo.org>]

On Saturday 22 August 2009, Chip Parker wrote:
> 2009/8/21 Robert Buchholz <rbu@gentoo.org>:
> > On Saturday 22 August 2009, Maciej Mrozowski wrote:
> >> It's true, but being able to modularize profile may outweights the
> >> need to be strict-with-the-book here - it's a matter of usefulness. I
> >> think it should be decided by those who actually do the work in
> >> profile, whether it's worthy to push this now instead of waiting for
> >> EAPI approval.
> >>
> >> So, can profile developers share their view?
> >
> > We have kept SLOT dependencies and other >EAPI-0 features out of the
> > tree profiles, introduced profile EAPI versioning to foster
> > interoperability. Now what you propose is to break this deliberate
> > upgrade process to introduce a feature no one proposed for the profiles
> > directory in the last years?
> >
> > 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.
> > I am not saying that this is the *fastest* way to innovate (although in
> > my opinion it is a good way to keep interoperability).
> > However this PMS process is what council has chosen for Gentoo, and
> > either you follow it, or you try to improve it (working with the PMS
> > subproject people), or you bring up a proposal to redefine how we
> > handle standards within the tree.
> >
> > Trying to ignore the fact this standard exists is a way to breakage.
> >
> >
> > Robert
>
> When the PMS "subproject" is overwhelmingly ruled by a single person
> who doesn't have official Gentoo developer status and yet it is
> allowed to remove features from portage (the reference implementation)
> that predated PMS at the direction of this same non-dev, you start to
> have a very big problem.
>
> If you were building a house, and the blueprints had been signed off
> on calling for 1 meter high doors, but the builder had built in 2
> meter high doors, would you then go back to the builder and require
> him to do something that makes those doors unusable for the vast
> majority of people entering the house?
>
> If this feature, which HAD been documented (in bugzilla and
> commitlogs) prior to the first RFC for PMS, had instead been added
> yesterday, I would completely agree that we should revert it and it
> should be part of a future specification. Since this is instead a
> situation where the blueprints were wrong and the builder was correct,
> let's not go throwing away our "normal sized" doors.
>
> Since I, as well as the only person who's loudly having an issue with
> portage and PMS not matching up in this respect, are both USERS and
> NOT Gentoo developers, it's my opinion that portage should be left
> alone and PMS should be corrected to align with the spirit, if not the
> letter of what was documented WELL after the initial commit that added
> the feature. And, since I and the main contributor to PMS are both
> users, it's also my opinion that NEITHER of us should have anything to
> do with the policy/specification defining package manager behavior for
> the most prolific package manager in use today.

Could all of you just let this go. In this case Ciaran is actually right. 
Furthermore, From the beginning of the project there has been behaviour which 
was technically allowed but not condoned for official packages. The more 
formalized approach with EAPI/PMS is no different. Now this thread is too long 
already, just shut up about it. If you find the portage behaviour desirable 
and want it allowed in the tree. Well, EAPI is the way to go. Remember EAPI is 
not established by Ciaran, but by the council.

Paul

-- 
Paul de Vrieze
Email: pauldv@gentoo.org