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 1QcYQy-0008VO-Vf for garchives@archives.gentoo.org; Fri, 01 Jul 2011 07:46:43 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 40E78E04D2; Fri, 1 Jul 2011 07:46:31 +0000 (UTC) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by pigeon.gentoo.org (Postfix) with SMTP id C1070E04D2 for ; Fri, 1 Jul 2011 07:46:30 +0000 (UTC) Received: (qmail invoked by alias); 01 Jul 2011 07:46:29 -0000 Received: from unknown (EHLO [192.168.11.3]) [88.150.6.75] by mail.gmx.net (mp064) with SMTP; 01 Jul 2011 09:46:29 +0200 X-Authenticated: #17204272 X-Provags-ID: V01U2FsdGVkX1+fefUA+Mafda32/Y35S+tNh1amlbvvm2G/9kOvoF fbmZniWREsxFkv Message-ID: <4E0D7B1E.8080808@gmx.de> Date: Fri, 01 Jul 2011 09:45:34 +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> In-Reply-To: <20110701071238.17dee2b8@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: fc3236aabec6d52b287d9d218929c2ea Am 01.07.2011 08:12, schrieb Ciaran McCreesh: > On Thu, 30 Jun 2011 20:48:46 +0200 > Sebastian Luther wrote: >>> Portage's behaviour is already broken there -- think what happens >>> when ebuilds get removed. >> >> 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). Someone needs to ask them if you want that in EAPI5. >>>> Could you please give a summary (or point me to one) of the >>>> discussion about :=/:*? >>> >>> See the original EAPI 3 discussion. It's all there. >>> >> Yeah, the whole discussion is there, but not a summary. I don't have >> the time to wade through all these mails. > > Part of the reason EAPI 3 dragged on for so long was that rather than > reading the discussion, people would say "I've not read the entire > thread, but it seems to me that ...", and then the entire discussion > would have to be repeated all over again. 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. > > 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". > Nearly all packages that dep upon a slotted dependent have one of two > behaviours: they're ok with any slot that matches the rest of the spec > (including switching at runtime), or they need the best slot that was > present at install time. The former is :*, the latter :=. > > There are a few perverse cases that don't fit these. Those need special > fancy handling, and they're sufficiently fiddly that we shouldn't be > holding up solving the large number easy cases to deal with one or two > weird packages. > Agreed. >> Isn't it desirable that different PMs handle the "no operator" case in >> the same way (independently of the question of having one or both >> operators available)? > > 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? 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)?