[Rpm-maint] rpmtsOrder failed,

2008-06-23 Thread Johnson, Richard 
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?

Thanks,
--rich
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
https://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] rpmtsOrder failed,

2008-06-23 Thread Panu Matilainen 

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

RE: [Rpm-maint] rpmtsOrder failed,

2008-06-23 Thread Johnson, Richard 

-Original Message-
From: Panu Matilainen [mailto:[EMAIL PROTECTED] 
Sent: Monday, June 23, 2008 10:06 AM
To: Johnson, Richard
Cc: rpm-maint@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
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
https://lists.rpm.org/mailman/listinfo/rpm-maint