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 1SOzc7-000603-1A for garchives@archives.gentoo.org; Mon, 30 Apr 2012 23:02:39 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2EE71E075C; Mon, 30 Apr 2012 23:02:30 +0000 (UTC) Received: from mo-p05-ob.rzone.de (mo-p05-ob.rzone.de [81.169.146.181]) by pigeon.gentoo.org (Postfix) with ESMTP id C8366E075C for ; Mon, 30 Apr 2012 23:02:29 +0000 (UTC) X-RZG-AUTH: :IW0NeWCpcPchHrcnS4ebzBgQnKHTmUiSF2JlOcyz+57jTVMtVX7471ELeN8= X-RZG-CLASS-ID: mo05 Received: from pinacolada.localnet (95-130-166-116.hsi.glasfaser-ostbayern.de [95.130.166.116]) by smtp.strato.de (josoe mo54) (RZmta 28.16 AUTH) with ESMTPA id N01814o3UI7xJ3 for ; Tue, 1 May 2012 01:02:29 +0200 (CEST) From: "Andreas K. Huettel" To: gentoo-pms@lists.gentoo.org Subject: Re: [gentoo-pms] Re: EAPI 5 Date: Tue, 1 May 2012 01:02:48 +0200 User-Agent: KMail/1.13.7 (Linux/3.3.1-gentoo; KDE/4.8.2; x86_64; ; ) References: <20120415021641.1858ffde@gentoo.org> <201205010040.32421.dilfridge@gentoo.org> <20120430234420.70607954@googlemail.com> In-Reply-To: <20120430234420.70607954@googlemail.com> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Package Manager Specification discussions X-BeenThere: gentoo-pms@gentoo.org X-BeenThere: gentoo-pms@lists.gentoo.org Reply-To: gentoo-pms@lists.gentoo.org MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201205010102.49051.dilfridge@gentoo.org> X-Archives-Salt: fe864114-325d-4292-bf63-44f0f494c219 X-Archives-Hash: e9dfc6d361dceb909194e383cbc7339d Am Dienstag 01 Mai 2012, 00:44:20 schrieb Ciaran McCreesh: > "Andreas K. Huettel" wrote: > > > I'm against this one in a "quick" EAPI, unless you can get a > > > reference implementation and extensive testing on possible use > > > scenarios done in time. I strongly suspect this will end up having > > > the problems that REQUIRED_USE had when it was shoved in at the > > > last minute without anyone having properly tried it out... > > > > I cannot say much myself about the complexity of the reference > > implementation, however the concept itself is imho pretty > > straightforward and (in particular) not intrusive. > > Can you enumerate every possible way the files will be used, both in > terms of syntax and intended effect? In the same way as package.use.mask and package.use.force. > Can you provide assurances that it > can't also be (ab)used to do other things not on your list? Which list? Of course someone will come up with other creative ideas how to (ab)use it, that's the nature of things. (I mean, people even write other package manglers replacing portage... :) > Can you demonstrate that introducing this in an EAPI won't require > upping profile EAPIs, No. Teach me, please. An indication might however be that it acts on a package level. > and that users whose package mangler doesn't do > EAPI 5 won't run into problems with it? Well. PMS describes the files in a profile directory. If * we introduce a new file via PMS that was not in there before, * and another package manager accesses that file but expects different information there not corresponding to our new definition, that package manager should be considered broken because it is not adhering to previous PMS revisions. So? > > The interaction of the various use related profile things is already > very complicated and messy. We still haven't decided what happens when > use dependencies become allowed in profiles, and we're keeping profile > EAPIs locked below 2 so we don't have to figure it out. -- Andreas K. Huettel Gentoo Linux developer dilfridge@gentoo.org http://www.akhuettel.de/