[Rpm-maint] rpmtsOrder failed,

[Johnson, Richard]

-----Original Message-----
From: Panu Matilainen [mailto:pmatilai at redhat.com] 
Sent: Monday, June 23, 2008 10:06 AM
To: Johnson, Richard
Cc: rpm-maint at lists.rpm.org
Subject: Re: [Rpm-maint] rpmtsOrder failed, 
On Mon, 23 Jun 2008, Panu Matilainen wrote:

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

Now THAT's what I call a prompt response!  

Kudos & thanks for the explanation.

--rich