From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-dev+bounces-54841-garchives=archives.gentoo.org@lists.gentoo.org>
Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80])
by finch.gentoo.org (Postfix) with ESMTP id 70479138010
for <garchives@archives.gentoo.org>; 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 <gentoo-dev@lists.gentoo.org>; Tue, 18 Sep 2012 23:28:48 +0000 (UTC)
Received: by pbbrp16 with SMTP id rp16so478048pbb.40
for <gentoo-dev@lists.gentoo.org>; 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 <ferringb@gmail.com>
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: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
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 <ciaran.mccreesh@googlemail.com> wrote:
>
> > On Wed, 19 Sep 2012 00:01:21 +0200
> > Micha?? G??rny <mgorny@gentoo.org> wrote:
> > > On Tue, 18 Sep 2012 22:37:19 +0100
> > > Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > > > On Tue, 18 Sep 2012 23:34:29 +0200
> > > > Micha?? G??rny <mgorny@gentoo.org> wrote:
> > > > > On Tue, 18 Sep 2012 22:08:43 +0100
> > > > > Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > > > > > On Tue, 18 Sep 2012 23:06:06 +0200
> > > > > > Micha?? G??rny <mgorny@gentoo.org> 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