From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1MfEyG-0004Qs-Pt for garchives@archives.gentoo.org; Sun, 23 Aug 2009 15:27:05 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 10DB2E035B; Sun, 23 Aug 2009 15:27:03 +0000 (UTC) Received: from viefep20-int.chello.at (viefep20-int.chello.at [62.179.121.40]) by pigeon.gentoo.org (Postfix) with ESMTP id 8C6FBE035B for ; Sun, 23 Aug 2009 15:27:02 +0000 (UTC) Received: from edge04.upc.biz ([192.168.13.239]) by viefep20-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20090823152659.CNXN9018.viefep20-int.chello.at@edge04.upc.biz> for ; Sun, 23 Aug 2009 17:26:59 +0200 Received: from oct.localnet ([84.74.48.6]) by edge04.upc.biz with edge id XrSx1c0FD080h7Y04rSz54; Sun, 23 Aug 2009 17:26:59 +0200 X-SourceIP: 84.74.48.6 From: Paul de Vrieze To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant' Date: Sun, 23 Aug 2009 17:26:56 +0200 User-Agent: KMail/1.12.0 (Linux/2.6.30.4; KDE/4.3.0; i686; ; ) References: <90b936c0908121058y5fd25cfcm67a19761b1130896@mail.gmail.com> <200908220145.00956.rbu@gentoo.org> <9f2790160908211729w79e1a838i8daf2e3df096c6bb@mail.gmail.com> In-Reply-To: <9f2790160908211729w79e1a838i8daf2e3df096c6bb@mail.gmail.com> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <200908231726.56698.pauldv@gentoo.org> X-Archives-Salt: 5e7b7751-942d-4635-89c0-3601686617a4 X-Archives-Hash: c156c38bac24cf094aea70ee0c14bb73 On Saturday 22 August 2009, Chip Parker wrote: > 2009/8/21 Robert Buchholz : > > 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