On Mon, 23 Jun 2008, Johnson, Richard wrote:
Folks--
I've been having a bear of a time installing a suite of rpms where all
dependencies are satisfied, only to fail in tsOrder. I've tracked the
error down to this snippet from lib/depends.c (nrescans is initially 10)
1388 /* If a relation was eliminated, then continue sorting. */
1389 /* XXX TODO: add control bit. */
1390 if (nzaps && nrescans-- > 0) {
1391 rpmlog(RPMLOG_DEBUG, "========== continuing tsort ...\n");
1392 goto rescan;
1393 }
Increasing the allowable rescans enables install to proceed. This makes
me wonder why rescans are limited in the first place. My reading is
that as long as nzaps!=0 progress was made and a rescan is appropriate.
Or could someone enlighten me otherwise?
Ah, that... Indeed the limit of 10 is artificial, no real reason to stop
when progress can be made. Hitting that limit says you have a lot of
dependency loops in your package set (and probably a large set of packages
too). Now, dependency loops aren't exactly a good thing but failing
unnecessarily is just silly.
This was recently encountered in Fedora too and the artificial limit
removed there, only I forgot to apply it upstream (done now). Thanks for
reminding me :)
- Panu -
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
https://lists.rpm.org/mailman/listinfo/rpm-maint