Hide Forgot
Description of problem: The description contained in the spec file is outdated. It references the previous release. The last line of the description is: "This package (bash) contains bash version 3.1, which improves POSIX compliance over previous versions." Obviously, the bash 4.1 package does NOT contain bash 3.1. That block should be removed or rewritten as to not include a version string. Version-Release number of selected component (if applicable): bash-4.1.2-4.fc13.src.rpm How reproducible: Always. Steps to Reproduce: 1. Open spec file in editor 2. Search for %description 3. See outdated / incorrect information Actual results: The description notes the included bash version is 3.1. Expected results: The description should not note the version number as there are other fields (specifically the Version section of the spec) to note the package version. Additional info:
The src.rpm in rawhide also has this typo (bash-4.1.7-1.fc14.src.rpm). Would you like a second ticket opened or can you just clone this one?
Thanks for the report. One ticket is enough, thanks.
I'm sorry, but there is no such line. From where do you have those rpms?
The rpms are from different sources (gatech, mirrordenver.fdcservers.net, and a 3rd mirror). Ok, I think I've found something that is very different than I first reported, so I apologize for the initial inconvenience. If I use "rpm -qip bash-4.1.7-1.fc14.src.rpm --queryformat '%{description}'" or just "rpm -qip bash-4.1.7-1.fc14.src.rpm", I am shown the incorrect descriptions. I am on RHEL 5.4. If I use "less bash-4.1.7-1.fc14.src.rpm", I see only 1 copy of the description, but it is the wrong one. If I uncompress the src.rpm and look at the bash.spec, it is the correct one. The same thing happens on a fully patched CentOS server (5.4) as well as RHEL 5.2. Would this be an rpm bug for RHEL? ################################### Name : bash Relocations: (not relocatable) Version : 4.1.7 Vendor: Fedora Project Release : 1.fc14 Build Date: Fri 21 May 2010 12:19:35 PM CDT Install Date: (not installed) Build Host: xb-01.phx2.fedoraproject.org Group : System Environment/Shells Source RPM: (none) Size : 6684518 License: GPLv3+ Signature : (none) Packager : Fedora Project URL : http://www.gnu.org/software/bash Summary : The GNU Bourne Again shell (bash) version 3.1. Description : The GNU Bourne Again shell (Bash) is a shell or command language interpreter that is compatible with the Bourne shell (sh). Bash incorporates useful features from the Korn shell (ksh) and the C shell (csh). Most sh scripts can be run by bash without modification. This package (bash) contains bash version 3.1, which improves POSIX compliance over previous versions. The GNU Bourne Again shell (Bash) is a shell or command language interpreter that is compatible with the Bourne shell (sh). Bash incorporates useful features from the Korn shell (ksh) and the C shell (csh). Most sh scripts can be run by bash without modification. This package (bash) contains bash version 3.1, which improves POSIX ############################ If I run the same command on an Ubuntu server (as I have the rpm command available), it shows the description properly and not the incorrect description. Obviously being that it is Ubuntu, there is not a local rpm database to incorrectly pull a description from when displaying the query. Still.. rpm -qip and less both display incorrectly on RHEL 5.x machines, which probably shouldn't happen.
The problem is in spescpo package. Rpm is looking into specspo files for localizations. This specspo package in RHEL5 contains localizations for RHEL5's bash - therefore bash-3.1. If you uninstall specspo package, there should be right Summary and Description. However, the specspo package in RHEL5 shouldn't have localization for C language. It's nonsense, since spec files are written in C language. In rawhide it's ok, no C locales.
This issue a low risk problem that will be addressed in future versions of RHEL. If you feel that this has to be resolved in current RHEL release, please contact redhat.com/support to raise the priority of this issue.
Ah, that helps clear up my confusion. I can live with it as a known issue as it has existed unreported / undetected for this long. Thank you for the explanation.