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 1QcZW8-0006mj-US for garchives@archives.gentoo.org; Fri, 01 Jul 2011 08:56:05 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id AC5AA1C005; Fri, 1 Jul 2011 08:55:56 +0000 (UTC) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by pigeon.gentoo.org (Postfix) with SMTP id 323D21C005 for ; Fri, 1 Jul 2011 08:55:55 +0000 (UTC) Received: (qmail invoked by alias); 01 Jul 2011 08:55:54 -0000 Received: from unknown (EHLO [192.168.11.3]) [88.150.6.75] by mail.gmx.net (mp014) with SMTP; 01 Jul 2011 10:55:54 +0200 X-Authenticated: #17204272 X-Provags-ID: V01U2FsdGVkX19OY5N2wfNO89XO4lQNJ7x22pFzMipRjdgfowhNNs fKrLfLRJcMbec0 Message-ID: <4E0D8B63.7010103@gmx.de> Date: Fri, 01 Jul 2011 10:54:59 +0200 From: Sebastian Luther User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110506 Lightning/1.0b3pre Thunderbird/3.1.10 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 To: gentoo-pms@lists.gentoo.org Subject: Re: [gentoo-pms] Do we want an EAPI 5? References: <20110630113154.32b8db1f@googlemail.com> <4E0C6F6A.9090807@gmx.de> <20110630182258.5fb6ab5f@googlemail.com> <4E0CC50E.2040002@gmx.de> <20110701071238.17dee2b8@googlemail.com> <4E0D7B1E.8080808@gmx.de> <20110701090908.7804e653@googlemail.com> In-Reply-To: <20110701090908.7804e653@googlemail.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Archives-Salt: X-Archives-Hash: 961361495973dcefb9858c360b998d68 Am 01.07.2011 10:09, schrieb Ciaran McCreesh: > On Fri, 01 Jul 2011 09:45:34 +0200 > Sebastian Luther wrote: >>>> I know. I'm not opposed to this change, but the needed work flow >>>> change for ebuild devs has to be communicated. >>> >>> Shouldn't be a workflow change. It's already policy to do a revbump >>> if dependencies change. >> >> It is policy, but as you're probably aware of, it's not followed in >> may cases, which in turn raises the question if people wouldn't >> prefer to change the policy instead of their work flow (not that I >> would suggest that). > > Anyone not following the policy is already breaking things, and we > can't switch to the "use the tree ebuild" behaviour since it doesn't > work when ebuilds get removed. All we're doing is making an existing > bug more visible. The "make the bug more visible part" is what I'm up to. > >> I think part of the problem here is that those things aren't written >> down as a glep (or some similar document). Imo every change that leads >> to a non trivial amount of discussion should be written down in such a >> way. Otherwise it's hard for people that missed the original >> discussion to catch up and those that took part in this discussion >> get frustrated because they have to repeat themselves again and again. >> This should be discussed in another thread if someone is interested. > > It's not worth it. It's a huge amount of work to summarise every > incorrect argument and false lead. It's not done by official standards > bodies, who have far more resources than we do, so what you're asking > for is just obstructionism and red tape. > I'm not asking for a summary of everything someone said about the topic. I'm asking for something between this and a PMS text, simply put, the stuff that is mandated by the glep rules. >>> If you're just looking for a summary, not details: say a user has >>> cat/dep:1, cat/dep:2 and cat/dep:3 installed, and wants to uninstall >>> cat/dep:1 and cat/dep:2. Say there's cat/pkg installed which has a >>> dep upon cat/dep. Then there's no way for the package mangler to >>> know which cat/dep slots are still 'needed', and which can be safely >>> removed. Thus, to be safe, it has to assume that all three slots >>> might be needed. >>> >> Or you do it like portage does it and assume the package works with >> any slot (the :* case) and if it doesn't, declare that a bug of the >> package. Now giving ebuild devs the := operator allows them to say >> "the package insist on the slot it was build against". > > Can't. Right now there's no way for packages to specify those kinds of > dependencies correctly. Assuming :* just isn't safe, and doesn't match > the historical meaning of lack-of-slot dependencies. > I don't know what you mean with historical meaning. As long as I use gentoo (since ~mid 2007) it has been that way. I agree that it isn't safe, but that's how portage does it. For EAPI5, there is the possibility to make this the default and leave := for the cases that don't behave this way (see below). >>> The problem is that every way of handling the "no operator" case is >>> wrong for many real situations. You can assume either "any slot" or >>> "best slot", both of which will allow packages to be removed >>> unsafely, or you can assume "all slots", which is excessively >>> paranoid for many packages. >>> >> Do you see a way for the PM to decide which behavior it should use on >> per case basis? > > The package mangler has to be told explicitly. It can't work it out > itself. > >> If yes, than having both operators makes sense. >> If no, the PM has to decide on one of the behaviors anyways. Why not >> specify which one that is (see above)? > > Having both operators provides a way of checking that developers have > explicitly confirmed which behaviour they mean. Without them, we don't > know whether no operator means "whichever default we decide", or > whether it means "I didn't realise that this dep has slots now". > Right, that's lost when a default is selected. It now boils down to the question what people want. a) The proposal that had been voted into EAPI3. b) What I said above. The first having the advantage that it's possible to check if a dep has been updated to slot deps or not. The latter has the advantage that it's simpler in the sense that it introduces only one new thing (the := operator) to do one new thing, namely to turn the :* behavior most people (those that use portage) are used to into the := behavior. It also doesn't leave any uncertainty about what the "no-operator" case means.