Bug 835310

Summary: rpm -qpi should ignore specspo
Product: Red Hat Enterprise Linux 5 Reporter: Jaroslav Škarvada <jskarvad>
Component: rpmAssignee: Panu Matilainen <pmatilai>
Status: CLOSED WONTFIX QA Contact: BaseOS QE Security Team <qe-baseos-security>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 5.9   
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-06-27 03:25:22 EDT Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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):
rpm-4.4.2.3-27.el5

How reproducible:
Always

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.