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 1QcX0l-0008VA-QM for garchives@archives.gentoo.org; Fri, 01 Jul 2011 06:15:32 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id CD9D01C013; Fri, 1 Jul 2011 06:15:21 +0000 (UTC) Received: from mail-ww0-f53.google.com (mail-ww0-f53.google.com [74.125.82.53]) by pigeon.gentoo.org (Postfix) with ESMTP id 749D91C013 for ; Fri, 1 Jul 2011 06:15:21 +0000 (UTC) Received: by wwf26 with SMTP id 26so2621961wwf.10 for ; Thu, 30 Jun 2011 23:15:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; bh=9YU0x3EHKjRF2K6vorSDohOWkdDzoaaUycdXSnBXk9w=; b=qcAoBhPny2RcjehwCUxKOY7/pRzZ53NpUieSiT+7Ad5RSiDsSVuj5n80U/CP6wMTcy Yqi2ob1AJ9ZX45eTB5JWy0yX5ZO3Z/oUWqQ0MxAELDj01HqRpCMNlV7vjeIy//qYHNjm pO0tTwAjRgi0A39+8c+kAv+gsPLKS6TjR/hcg= Received: by 10.227.206.133 with SMTP id fu5mr2549791wbb.31.1309500920621; Thu, 30 Jun 2011 23:15:20 -0700 (PDT) Received: from localhost (cpc1-broo4-0-0-cust780.14-2.cable.virginmedia.com [86.4.215.13]) by mx.google.com with ESMTPS id o19sm2111476wbh.21.2011.06.30.23.15.19 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 30 Jun 2011 23:15:20 -0700 (PDT) Date: Fri, 1 Jul 2011 07:12:38 +0100 From: Ciaran McCreesh To: gentoo-pms@lists.gentoo.org Subject: Re: [gentoo-pms] Do we want an EAPI 5? Message-ID: <20110701071238.17dee2b8@googlemail.com> In-Reply-To: <4E0CC50E.2040002@gmx.de> References: <20110630113154.32b8db1f@googlemail.com> <4E0C6F6A.9090807@gmx.de> <20110630182258.5fb6ab5f@googlemail.com> <4E0CC50E.2040002@gmx.de> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.5; x86_64-pc-linux-gnu) 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: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/7BHTv_1BS/sEP+oKjMQZY=+"; protocol="application/pgp-signature" X-Archives-Salt: X-Archives-Hash: 43184ed2feffd0f556838fd246579c0c --Sig_/7BHTv_1BS/sEP+oKjMQZY=+ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable 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. >=20 > 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. > >> Could you please give a summary (or point me to one) of the > >> discussion about :=3D/:*? > >=20 > > See the original EAPI 3 discussion. It's all there. > >=20 > 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. 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. 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 :=3D. 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. > 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. --=20 Ciaran McCreesh --Sig_/7BHTv_1BS/sEP+oKjMQZY=+ Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iEYEARECAAYFAk4NZVoACgkQ96zL6DUtXhFrdACfflKiX1hDAU1a4zIyupz8lyMB Ja0An0QozSfRd1LliSR3QehC+yZhF4h7 =mtjD -----END PGP SIGNATURE----- --Sig_/7BHTv_1BS/sEP+oKjMQZY=+--