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

Reply via email to