From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 70479138010 for ; Tue, 18 Sep 2012 23:30:14 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8A5C121C033; Tue, 18 Sep 2012 23:29:45 +0000 (UTC) Received: from mail-pb0-f53.google.com (mail-pb0-f53.google.com [209.85.160.53]) by pigeon.gentoo.org (Postfix) with ESMTP id 04A4BE06CC for ; Tue, 18 Sep 2012 23:28:48 +0000 (UTC) Received: by pbbrp16 with SMTP id rp16so478048pbb.40 for ; Tue, 18 Sep 2012 16:28:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=Mpb2N8bi1eETb+wPn5XcevNqmxVp6NxwZMXJAImCXPM=; b=U0sj0oG+K5aKom1usMaUGZYyO5AgBllkB6Z6dHjfUEPkx/S/i+M8VrCkQOFQlGQx+/ CPXPZzaiB4s+kk3FcWz6Csz+G1Sp6FEGndf0uLW/zeKA2G/tZxOMkwk0lxej6hiUSl6U dONg9dXhP9qo2wt6vlXSw6kUIeUT6oeVy111zG4Mt/j0R/QnQMcyVBZjpiDBRi9FUNDp bdWhCx5ICUgq0R9qX497ss0W0Izc8tJlD0givg3IL61QwpFqQgA6l4t5uJeFBpXxUrHX sXh77aR2aSIVeO4RKElIcgr8eLgHR1OOlbnV2c+YfTpVgqx1+MP1j1rxyMQxnfuRyx0j wV7g== Received: by 10.68.234.73 with SMTP id uc9mr2415358pbc.158.1348010928213; Tue, 18 Sep 2012 16:28:48 -0700 (PDT) Received: from smtp.gmail.com:587 (74-95-192-101-SFBA.hfc.comcastbusiness.net. [74.95.192.101]) by mx.google.com with ESMTPS id rm6sm716530pbc.54.2012.09.18.16.28.45 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 18 Sep 2012 16:28:47 -0700 (PDT) Received: by smtp.gmail.com:587 (sSMTP sendmail emulation); Tue, 18 Sep 2012 16:28:59 -0700 Date: Tue, 18 Sep 2012 16:28:59 -0700 From: Brian Harring To: gentoo-dev@lists.gentoo.org Cc: ciaran.mccreesh@googlemail.com Subject: Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal Message-ID: <20120918232859.GG5384@localhost> References: <20120918204433.52af8bcd@googlemail.com> <20120918225104.567ca679@pomiocik.lan> <20120918215355.7ee46043@googlemail.com> <20120918230606.03d994f2@pomiocik.lan> <20120918220843.39868fd0@googlemail.com> <20120918233429.277a4726@pomiocik.lan> <20120918223719.790e1477@googlemail.com> <20120919000121.52d12484@pomiocik.lan> <20120918230619.58c30ef9@googlemail.com> <20120919005309.1265dc30@pomiocik.lan> 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=us-ascii Content-Disposition: inline In-Reply-To: <20120919005309.1265dc30@pomiocik.lan> User-Agent: Mutt/1.5.21 (2010-09-15) X-Archives-Salt: 8d3bf38a-6722-4c4d-9e7e-38a63820e2e4 X-Archives-Hash: bad418f973d98f1fdf6aa0f242044f1e On Wed, Sep 19, 2012 at 12:53:09AM +0200, Micha?? G??rny wrote: > On Tue, 18 Sep 2012 23:06:19 +0100 > Ciaran McCreesh wrote: > > > On Wed, 19 Sep 2012 00:01:21 +0200 > > Micha?? G??rny wrote: > > > On Tue, 18 Sep 2012 22:37:19 +0100 > > > Ciaran McCreesh wrote: > > > > On Tue, 18 Sep 2012 23:34:29 +0200 > > > > Micha?? G??rny wrote: > > > > > On Tue, 18 Sep 2012 22:08:43 +0100 > > > > > Ciaran McCreesh wrote: > > > > > > On Tue, 18 Sep 2012 23:06:06 +0200 > > > > > > Micha?? G??rny wrote: > > > > > > > But didn't we already point out that we can't have them in > > > > > > > RDEPEND since they introduce conflicts? > > > > > > > > > > > > You are missing a basic and important part of how dependency > > > > > > resolution works: currently, cycles consisting purely of > > > > > > RDEPENDs are ignorable. > > > > > > > > > > So, what do we lose? If PDEP comes 'ASAP' officially, I believe > > > > > that we actually gain RDEPs which can be actually trusted. > > > > > > > > "ASAP" is a weaker guarantee that RDEPENDs currently have -- > > > > RDEPENDs currently have the weakest guarantee necessary to ensure > > > > that they can be trusted. It's also a useless guarantee, since > > > > "ASAP" can be arbitrarily late. > > > > > > And can't RDEPENDs be arbitrarily late if there is a cycle? > > > > No. RDEPENDs have to be available when a package is used to satisfy a > > dependency. That's the difference between an RDEPEND and a PDEPEND. > > So, if a particular cycle prohibits RDEPENDs being fulfilled when > RDEPEND is needed to satisfy a dependency, we have a failure now, > correct? Depends on the cycle, but yes. Order of depdencies for this converation; depends is strongest, rdepends is second, pdepend is weak. If a pkg both deps and rdeps on something, for building (since that's the first op), dep obviously trumps all other dep forms for that pkg. pkg1 depends <-> pkg2 depends cycle, we're boned, unsolvable; use dep toggling at best. pkg1 rdepends -> pkg2, pkg2 depends on pkg1, strictly speaking, we're boned; pkg1 isn't considered 'usable' until pkg2 is considered 'usable'. This is the common case where use pdepend instead of rdep. pkg1 rdepends <-> pkg2 rdepends; this is a contained cycle, and is mergable. Now if for pkg1 rdep<->pkg2 rdep, pkg2 rdeps on pkg3 (which neds to be built), which deps on pkg1 this too, is an unsolvable chain. you can build pkg1 and pkg2, and even install them. But pkg3 cannot be built until pkg1 is considered 'usable', which can't be be considered usable till pkg2 is considered usable, which (take a guess where I'm going with this) can't be considered usable until pkg3 is considered usable. > Do we have that guarantee somewhere in the PMS? It's not too hard to check in the doc yourself, ya know. ;) relevant latex chunk: """ \begin{compactitem} \item Build dependencies (\t{DEPEND}). These must be installed and usable before any of the ebuild \t{src\_*} phase functions is executed. These may not be installed at all if a binary package is being merged. \item Runtime dependencies (\t{RDEPEND}). These must be installed and usable befor the results of an ebuild merging are treated as usable. \item Post dependencies (\t{PDEPEND}). These must be installed at some point before the package manager finishes the batch of installs. \end{compactitem} """ keyword there is 'usable'. Wording could be expanded, but the core notion is there- it just skips going over graph theory/resolver guts/cycles since they're not explicitly a property of dependecy types. Feel free to write a patch expanding the wording htere... ~harring