Bug 835310 - rpm -qpi should ignore specspo
rpm -qpi should ignore specspo
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: rpm (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Panu Matilainen
BaseOS QE Security Team
Depends On:
  Show dependency treegraph
Reported: 2012-06-25 19:21 EDT by Jaroslav Škarvada
Modified: 2012-06-27 03:25 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-06-27 03:25:22 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jaroslav Škarvada 2012-06-25 19:21:42 EDT
Description of problem:
rpm -qpi should ignore specspo

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. yum install specspo
1. get (for example pm-utils) SRPM, change description, build
2. rpm -qpi RPM
Actual results:
Old description

Expected results:
New description

Additional info:
IMHO if used on locally stored RPMs with the -p switch it should show what is exactly in the RPM.
Comment 1 Panu Matilainen 2012-06-27 03:25:22 EDT
NAK. One of the important uses of specspo is to allow non-English speakers to get a clue about the packages they're about to install, and this would make specspo even more useless than it is now. Also this behavior is actually intentional part of specspo "design": it avoids breaking all translations when somebody fixes a typo or such in the actual package description.

The flip-side of course is the confusing behavior you're seeing (you're certainly not the first one to complain about this). In RHEL-6 specspo lookups are done directly on the actual string from the package (instead of going through name(tag) C-locale lookup first) so when the strings in package change, that's what you get... at the cost of breaking all translations.

It would be possible to change RHEL-5 to use direct lookups too, which would fix this issue but OTOH cause unknown amount of translation regressions unless specspo gets a major update too. I dont think its worth the trouble messing with it for RHEL-5, packagers are best off just doing 'rpm -e specspo' to get it out of the way.

Note You need to log in before you can comment on or make changes to this bug.