Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Brian Harring <ferringb@gmail.com>]

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