Description of problem: dnf is refusing to install a certain noarch rpm package. Version-Release number of selected component (if applicable): 2.7.5-2.fc27 How reproducible: Always, for one particular file Steps to Reproduce: 1. sudo dnf install tvbrowser-4.0.1-1.noarch.rpm Actual results: Error: Will not install a source rpm package (tvbrowser-4.0.1-1.src). Expected results: Installs Additional info: The package tvbrowser-4.0.1-1.noarch.rpm is from here: http://sourceforge.net/projects/tvbrowser/files/TV-Browser%20Releases%20%28Java%208%20and%20higher%29/4.0.1/tvbrowser-4.0.1-1.noarch.rpm/download The "rpm" program does not refuse to install (but it handles src.rpms anyway): [barsnick@goodtimes Downloads]$ sudo rpm -ivh --test tvbrowser-4.0.1-1.noarch.rpm Preparing... ################################# [100%] The "file" program recognizes it as a binary rpm: [barsnick@goodtimes Downloads]$ file tvbrowser-4.0.1-1.noarch.rpm tvbrowser-4.0.1-1.noarch.rpm: RPM v3.0 bin tvbrowser-4.0.1-1 I can add --debugsolver output, if requested. Perhaps you can just reproduce.
Headers of this tvbrowser-4.0.1-1.noarch.rpm looks like this: $ rpm -qip tvbrowser-4.0.1-1.noarch.rpm Name : tvbrowser Epoch : 0 Version : 4.0.1 Release : 1 Architecture: noarch Install Date: (not installed) Group : Java Size : 8195754 License : Signature : (none) Source RPM : (none) Build Date : Út 6. březen 2018, 16:08:17 CET Build Host : notebookL Relocations : (not relocatable) Packager : Standard Vendor : URL : Summary : Description : Dnf is not able to install it, because underlying libsolv library detect is as a source rpm. Basically because of absence of "Source RPM" tag. From my point of view it looks like incorrectly built package and you should ask it's author to include the "Source RPM" header. Just to be sure, I'd like to ask the rpm team: is there is any other way how to distinguish between source and binary rpm packages?
(In reply to Marek Blaha from comment #1) I'm not the rpm team, but let me answer: > Headers of this tvbrowser-4.0.1-1.noarch.rpm looks like this: [...] > Source RPM : (none) [...] > as a source rpm. Basically because of absence of "Source RPM" tag. So standard rpmbuild would guarantee presence of a "Source RPM" tag? What does the specification say? > Just to be sure, I'd like to ask the rpm team: is there is any other way how > to distinguish between source and binary rpm packages? Apparently, byte 6 and 7 (counting from 0) of the file header: https://github.com/file/file/blob/master/magic/Magdir/rpm Confirmed in the "specification": http://ftp.rpm.org/max-rpm/s1-rpm-file-format-rpm-file-format.html > From my point of view it looks like incorrectly built package and you should > ask it's author to include the "Source RPM" header. I will, once I'm sure it's a mandatory field.
Here's the heuristic in (lib)rpm which libsolv apparently uses: https://github.com/rpm-software-management/rpm/blob/27ea3f8624560bd158fc7bc801639310a0ffab10/lib/headerutil.c#L14
The package looks like perfectly ordinary 4.4.2 era binary rpm to be me, and rpm sees it as a binary package (source packages are not installed via transactions): $ rpm -Uvh ~/tvbrowser-4.0.1-1.noarch.rpm error: can't create transaction lock on /var/lib/rpm/.rpm.lock (Permission denied) AFAIK libsolv uses the same exact heuristics to determine source vs binary as rpm does (these days at least). Note heuristics as it's complicated (due to all sorts of different versions floating around, and not all packages are produced by rpmbuild): - RPMTAG_SOURCERPM presence is a positive id for a binary - RPMTAG_SOURCEPACKAGE presence is a positive id for a source - beyond that, a heuristic based on directory names is used, and this one clearly is a binary on that account too - package lead section contains binary vs source info (and which is what 'file' uses IIRC) but that's not longer used by rpm nor libsolv So maybe it's something in the stack above libsolv that gets it wrong.
I'm pretty sure that problem is in libsolv, because (in libdnf) we are just using what libsolv repo_add_rpm() function returns. Also solv command from libsolv-demo package says this: $ solv info tvbrowser-4.0.1-1.noarch.rpm Name: tvbrowser-4.0.1-1.src OK, I'll try to compare the libsolv heuristic with the rpm's one. There must be some difference in them. Can you please point me out where in rpm sources can I find source vs binary determination?
Hm, it looks like this error occurs only with certain versions of libsolv (specifically libsolv-0:0.6.34-1.fc27.x86_64). Please can you specify which version of the libsolv are you using? As a workaround, you can try downgrade to libsolv-0:0.6.29-2.fc27.x86_64 and see if it helps.
Oh, now I get it... The problem only occurs when libsolv is compiled with ENABLE_RPMPKG_LIBRPM: in "librpm mode" uses headerIsSource() which in this context is not sufficient: in rpm's usage, the necessary heuristics and retrofits to make headerIsSource() reliable happen in rpmReadPackageFile(), but that's not what libsolv uses.
I've created patch implementing for the libsolv the same heuristic as librpm uses. https://github.com/openSUSE/libsolv/pull/264 btw - what is the reason we cannot simply use type from rpm lead?
The lead as a data structure was officially abandoned over 20 years ago (old datastructures die hard :) so it'd seem wrong be using data from such a thing. More concretely, there are rpm versions out there that fill the lead with zeros to try drive the point across.
barsnick: the problem is fixed in the upstream version of libsolv. If you want to, you can try to install the libsolv from our nightly builds repo (https://copr.fedorainfracloud.org/coprs/rpmsoftwaremanagement/dnf-nightly/) by running # dnf update --nogpgcheck --repofrompath=dnfnightly,https://copr-be.cloud.fedoraproject.org/results/rpmsoftwaremanagement/dnf-nightly/fedora-27-x86_64/ libsolv (if you are still on F27)
I can confirm that installation now works with libsolv.x86_64 0.6.34-5g545fd9a1.fc27 from the dnf-nightly repo. Kudos and many thanks!
*** Bug 1578138 has been marked as a duplicate of this bug. ***