Runtime deps, binary packages and merge order
 

Just ran across the following thread in the forums yesterday:
http://forums.gentoo.org/viewtopic-t-626528.html

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
previously)

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
c) add a new deptype for merge dependencies - looks like overkill to me

Any other other ideas, comments, preferences?

Marius
--
gentoo-portage-dev@gentoo.org mailing list

Runtime deps, binary packages and merge order
 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Marius Mauch wrote:
> Just ran across the following thread in the forums yesterday:
> http://forums.gentoo.org/viewtopic-t-626528.html
>
> 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
> previously)
>
> 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 2.1.3.19.

I would encourage people to use PDEPEND whenever appropriate. Since
the fix for bug 176765 (2.1.2.6) 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.

Zac

> Any other other ideas, comments, preferences?
>
> Marius

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)

iD8DBQFHVuxy/ejvha5XGaMRAl81AJ4w9AxdA1s3TumsHd6QW18NXl6YXACgshl g
kTRZh6u5neywMTH5cPaGcSM=
=DFSH
-----END PGP SIGNATURE-----
--
gentoo-portage-dev@gentoo.org mailing list

Runtime deps, binary packages and merge order
 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Zac Medico wrote:
> 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 2.1.3.19.
>
> I would encourage people to use PDEPEND whenever appropriate. Since
> the fix for bug 176765 (2.1.2.6) it behaves very similar to
> RDEPEND, so it should be usable in more cases.

Pardon, I meant to say bug 180045 (2.1.2.10) instead of bug 176765.

Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)

iD8DBQFHVvCu/ejvha5XGaMRArxkAJ9cMk3Z17Dr9HDxA3FrCAPDouTyXACdEi9 F
KyA3JuRnEKnOK5LBkYREkbY=
=HSrt
-----END PGP SIGNATURE-----
--
gentoo-portage-dev@gentoo.org mailing list