RE: [Rpm-maint] Inconsistency between RPMTAG_Summary and %{SUMMARY}
Hello All:
First-off, thanks for the responses. It was all very helpful.
As suggested by Pixel, I first checked the XML of the header. It matched
that of the API call (i.e. also different from the command-line output).
Next, I took Peter's advice and changed the default language setting. The
install had this as en_US.utf-8. Changing this to 'en' made the output the
same (i.e. export LANG=en).
Thanks again for the help in resolving this issue!
Christopher
-Original Message-
From: Peter Bowen [mailto:[EMAIL PROTECTED]
Sent: Saturday, June 21, 2008 4:34 AM
To: learny
Cc: rpm-maint@lists.rpm.org
Subject: Re: [Rpm-maint] Inconsistency between RPMTAG_Summary and %{SUMMARY}
On Fri, 2008-06-20 at 13:50 -0700, learny wrote:
> I have encountered an issue regarding the Summary field and
> headerGetEntry() in rpm 4.4.2-37.el5. The string returned from the
> command-line differ from those of the API for the Summary for one
> package. While the difference are relatively trivial, I thought it
> worthy a question to the mailing list. Specifically, I have observed
> this only on RHED 5.0 only for the package cpuspeed. Other packages
> on this system do not exhibit this behavior, nor has this problem
> occurred on my testing of other RPM-based systems of the SuSE variety.
>
> I had just assumed that the command-line query tag of %{SUMMARY} maps
> to the API entry for RPMTAG_SUMMARY; however, this appears to not be
> the case. Is this a known issue and/or is there documentation on
> this?
I suspect you are running into a translated string. If you set your
environment to not specify a language, do you still see the issue?
While most programs are assumed to be have US English text as the
default, it is possible to have a US English transation associated with
the string. I suspect in this case "CPU frequency adjusting daemon. "
is in the RPM header as the "C" (untranslated) string and "CPU frequency
adjusting daemon" is in the header or look-aside list as the string that
matches your language.
Thanks.
Peter
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
https://lists.rpm.org/mailman/listinfo/rpm-maint
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
