Description of problem: One example: http://koji.fedoraproject.org/koji/taskinfo?taskID=1281540 While fedora-deluge.desktop contains: ------------------------------------------------ MimeType=application/x-bittorrent; ------------------------------------------------ $ rpm -q --provides deluge | grep mime returns nothing. Note that with file-5.00-5.fc11.i586 ------------------------------------------------ $ file /usr/share/applications/fedora-deluge.desktop /usr/share/applications/fedora-deluge.desktop: ASCII English text ------------------------------------------------ Another example: http://koji.fedoraproject.org/koji/taskinfo?taskID=1284705 Here fedora-mirage.desktop contains ----------------------------------------------- MimeType=image/bmp;image/gif;image/jpeg;image/jpg;image/pjpeg;image/png;image/tiff;image/x-bmp;image/x-pcx;image/x-png;image/x-portable-anymap;image/x-portable-bitmap;image/x-portable-graymap;image/x-portable-pixmap;image/x-sun-raster;image/x-tga;image/x-xbitmap;image/x-xpixmap;image/svg+xml; ----------------------------------------------- but $ rpm -ql --provides mirage-XXXX.i586.rpm | grep mime returns nothing. In this case $file fedora-mirage.desktop returns "ASCII text" It seems this is because rpmbuild only checks desktop file which returns "RPMFC_TEXT" color. Version-Release number of selected component (if applicable): rpm-4.7.0-0.beta1.9.fc11.i586 How reproducible: 100% Steps to Reproduce: 1. See above 2. 3.
(In reply to comment #0) > but $ rpm -ql --provides mirage-XXXX.i586.rpm | grep mime > returns nothing. This is $ rpm -qp --provides ...
(aside) Technically, there is no RPMFC_TEXT color because the bits are masked and not distributed. The RPMFC_FOO bits are purely a means to achieve a set of bits to be tested for filtering/dispatching helpers, not colors per se. If this flaw showed up recently, then its related to the recent choice to handle RPMFC_TEXT later in order to automate font automagic dependencies. Nothing wrong with handling RPMFC_ASCII later, the real flaw is within libmagic, mis-identifications with file(1) that are at least 20 years old and due to using the first rule that matches, which can cause rpmfc filtering flaws, particularly if system, rather than rpm internal, magic is used. Still magic is better than suffixes for file classification imho.
Created attachment 339822 [details] Here's one that is classified as "UTF-8 Unicode Pascal program text, with very long lines" which causes trouble
Created attachment 339823 [details] and one as "ASCII text, with very long lines" Here's one that is classified as "ASCII text, with very long lines" which causes trouble
Created attachment 339824 [details] a handle .src.rpm which shows no mimehandler provides based on those two .desktops A standalone .src.rpm testcase
*** Bug 495758 has been marked as a duplicate of this bug. ***
All that rpm does is use file(1) and libmagic with very light filtering to remove the worst of the problems. Issues with file(1) and magic(3) classification should be reported against file(1).
Should be fixed in rpm-4.7.0-2.fc12 (but it'll take quite some time before it hits the builders)
rpm-4.7.0-2.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/rpm-4.7.0-2.fc11
rpm-4.7.0-2.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.