[gentoo-portage-dev] 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 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-portage-dev] 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/ejvha5XGaMRAl81AJ4w9AxdA1s3TumsHd6QW18NXl6YXACgshlg kTRZh6u5neywMTH5cPaGcSM= =DFSH -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-portage-dev] 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/ejvha5XGaMRArxkAJ9cMk3Z17Dr9HDxA3FrCAPDouTyXACdEi9F KyA3JuRnEKnOK5LBkYREkbY= =HSrt -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
