RE: [Rpm-maint] rpmtsOrder failed,
-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
Re: [Rpm-maint] rpmtsOrder failed,
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
[Rpm-maint] rpmtsOrder failed,
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
