Runtime deps, binary packages and merge order
-----BEGIN PGP SIGNED MESSAGE-----
Marius Mauch wrote:
> Just ran across the following thread in the forums yesterday:
> Which raises an interesting point regarding merge order of runtime
> deps. IIRC we currently assume that it's ok to merge runtime deps after
> the depending package to resolve dep cycles for example, which is
> generally ok, except if a runtime dep is used in pkg_*. For
> ebuild-installs that can be worked around easily by using DEPEND (where
> order is strictly respected), but for binary packages that obviously
> doesn't work.
> This problem probably hasn't been recognized earlier as
> it requires several conditions to apply simultaneously (binary merge,
> circular rdeps, rdeps used in pkg_*, rdeps not installed
> Assuming I haven't missed anything, I see threee options to deal with
> that problem:
> a) ignore it, as it only affects a small minority
> b) respect merge order for RDEPEND - will cause more unsolvable
> depgraphs, though telling people to use PDEPEND more often might reduce
> that problem
The resolver currently tries to merge both RDEPEND and PDEPEND
before whenever possible. There is an optimization in 2.1.4_rc that
improves merge order in some circular RDEPEND cases, see the
cmp_circular_bias() function in depgraph.altlist(). There was
another related optimization for bug #189966 that's already in 184.108.40.206.
I would encourage people to use PDEPEND whenever appropriate. Since
the fix for bug 176765 (220.127.116.11) it behaves very similar to
RDEPEND, so it should be usable in more cases.
> c) add a new deptype for merge dependencies - looks like overkill to me
Actually, a new dep type seems pretty reasonable to me. We can
consider it part of bug 174552.
> Any other other ideas, comments, preferences?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
-----END PGP SIGNATURE-----
email@example.com mailing list