Description of problem: The package has no description due to a missing macro. Version-Release number of selected component (if applicable): 1.3-5 How reproducible: always Steps to Reproduce: 1. rpm -qp --qf "%{DESCRIPTION}" mingw32-openjpeg-1.3-5.fc13.src.rpm Actual results: %{_mingw32_description} %{_mingw32_debug_package} Expected results: (Some proper description.) Additional info: It seems rpmlint needs some new rules, e.g. for undefined macros.
This works fine if the package is installed: $ rpm -q --qf "%{DESCRIPTION}" mingw32-openjpeg This is the cross-compiled version of this library / tool. You should only install this package if you want to cross-compile programs for Win32 (32 bit Windows). $ rpm -qi mingw32-openjpeg Name : mingw32-openjpeg Relocations: (not relocatable) Version : 1.3 Vendor: Fedora Project Release : 5.fc12 Build Date: Mon 07 Dec 2009 12:35:58 AM GMT Install Date: Wed 30 Dec 2009 09:09:27 AM GMT Build Host: ppc3.fedora.redhat.com Group : Development/Libraries Source RPM: mingw32-openjpeg-1.3-5.fc12.src.rpm Size : 160422 License: BSD Signature : RSA/8, Mon 07 Dec 2009 01:48:50 PM GMT, Key ID 9d1cc34857bbccba Packager : Fedora Project URL : http://www.openjpeg.org/ Summary : MinGW Windows openjpeg library Description : This is the cross-compiled version of this library / tool. You should only install this package if you want to cross-compile programs for Win32 (32 bit Windows). I would say this could be a bug in the way rpm parses and displays the specfile embedded in an SRPM, although I doubt the rpm maintainers will agree. Reassigning to rpm ...
It even works for .src.rpms for me: $ rpm -qp --qf "%{DESCRIPTION}" mingw32-openjpeg-1.3-5.fc13.src.rpm This is the cross-compiled version of this library / tool. You should only install this package if you want to cross-compile programs for Win32 (32 bit Windows). What version of rpm are you using?
I've got this RPM package installed (I've got F10): rpm-4.6.1-3.fc10.i386 But that's no excuse, because Fedora Infrastructure suffers the same problem. I noticed the issue because I got the below e-mail on fedora-package-announce(at)redhat(dot)com. I'm personally not even interested in the package. ;-) (Until I build poppler for Windoze, or something like that.) -------------------------------------------------------------------------------- Fedora Update Notification FEDORA-2009-12884 2009-12-08 07:09:24 -------------------------------------------------------------------------------- Name : mingw32-openjpeg Product : Fedora 12 Version : 1.3 Release : 5.fc12 URL : http://www.openjpeg.org/ Summary : MinGW Windows openjpeg library Description : %{_mingw32_description} %{_mingw32_debug_package} --------------------------------------------------------------------------------
By the way, did you notice this rpmlint warning in the review ticket for mingw32-openjpeg (bug #537897)? mingw32-openjpeg.src: W: macro-in-%description %{_mingw32_description} Nobody really commented on that in the review, nor on the error: mingw32-openjpeg-debuginfo.noarch: E: debuginfo-without-sources
Rpm -qp only looks at the package's header, not the specfile. Whatever package provides those macros wasn't present when the src.rpm was generated, the spec itself is only parsed + macros expanded at build-time (and --specfile query). Whether this is an issue with Fedora build infrastructure or missing build-requires in the package I dunno, but doesn't look like an rpm bug to me (other than permitting unexpanded macros in the header but this is a chicken-egg syndrome of sorts, see bug 547997)
I'm highly inclined to close this NOTABUG, unless the reporter can come up with a reason why this is really a bug. Having macros in the %description section is very useful for the Fedora MinGW project, so that we can keep consistent description sections across a hundred or so packages.
Richard, please do read my original bug report and comment #3. I'm not against macros in the %description. But they should be resolved to make them useful. Neither my rpm version nor Fedora Infrastructure (again, see comment #3) see the intented content of the macro, but report only the unresolved macro. If that's acceptable to you, well, then *shrug*. If it's a backward compatibility issue, and you don't care about other rpm program versions (e.g. my F10's, or perhaps Mandriva's or SuSE's), and Fedora Infrastructure just needs to be updated, then please state that explicitly. Thanks.
The deal is that mock generates the src.rpm when buildrequires are not installed. So binary packages end up with correctly expanded macros, source packages have unexpanded. To fix this, mock needs to (re)generate the "exported" src.rpm once the buildrequires have been installed.
That would take us to the dark ages of having specific srpms for each arch, as some of the macros could be arch identifiers and other such non-sense. Honestly this looks like egregious overuse of macros, and not something I'd like to see proliferate further into our packages.
After talking with FESCo, we agree that we do not want this scenario happening, and we do not want to alter our buildsystem to try and make this half-work. So guidelines are being drafted that will disallow such macro use in spec files if it will lead to unexpanded macros (or empty macros if a ? is used) when build and published through Fedora's buildsystem.