Red Hat Bugzilla – Bug 171415
rpm -Uvh of custom snack package fails, but rpm -ivh succeeds on RHEL4u2
Last modified: 2015-01-07 19:11:03 EST
Description of problem: On a baseline version of RHEL4u2, rpm -Uvh of a custom binary rpm of a "snack" package fails to install (has dependencies with "newt"), but rpm -ivh of the same rpm will succeed. Version-Release number of selected component (if applicable): N/A How reproducible: should be easy. Create an arbitrary binary rpm and name it "snack-2.1.1-1.RHEL4.i686.rpm". The key is giving it a package name of "snack" with an appropriate version. Try installing it with: rpm -Uvh [should fail] Try installing via: rpm -ivh [should succeed] Steps to Reproduce: I am running a baseline copy of RHEL4 Update 2 and used a "Custom/Everything" installation. Steps involved to expose the RPM bug: 1) RHEL4u2 does not provide the freeware "snack" package. RHEL4u2 command prompt> rpm -q snack package snack is not installed 2) I built the "snack" 2.1.1 package from source on the RHEL4u2 box. I installed it into /usr/local/snack/lib. Only four files are built and installed (two shared libs and two tcl files): /usr/local/snack/lib/snack2.1/libsnack.so /usr/local/snack/lib/snack2.1/libsound.so /usr/local/snack/lib/snack2.1/pkgIndex.tcl /usr/local/snack/lib/snack2.1/snack.tcl 3) I tarred up the snack files (relative to /usr/local) and created a snack.tar.gz tarball. 4) I wrote a simple spec file which wrapped this tarball into an RPM with Relocation Prefix of /usr/local. So I ended up with a custom binary RPM named "snack-2.1.1-2.AWIPS.OB7.i686.rpm". Package is "snack" Version is "2.1.1" Release is "2.AWIPS.OB7.i686.rpm". 5) THE PROBLEM: "rpm -Uvh snack-2.1.1-2.AWIPS.OB7.i686.rpm" FAILS BUT.... "rpm -ivh snack-2.1.1-2.AWIPS.OB7.i686.rpm" WORKS! Here's output from rpm -Uvh: [root@bd17-napo usr-local]# rpm -Uvh snack-2.1.1-2.AWIPS.OB7.i686.rpm error: Failed dependencies: libnewt.so.0.51 is needed by (installed) authconfig-4.6.10-rhel4.1.i386 libnewt.so.0.51 is needed by (installed) kudzu-1.1.95.15-1.i386 libnewt.so.0.51 is needed by (installed) netconfig-0.8.21-1.1.i386 libnewt.so.0.51 is needed by (installed) ntsysv-1.3.13.2-1.i386 libnewt.so.0.51 is needed by (installed) setuptool-1.17-2.i386 libnewt.so.0.51 is needed by (installed) system-config-securitylevel-tui-1.4.19.2-1.i386 libnewt.so.0.51 is needed by (installed) newt-perl-1.08-7.i386 libnewt.so.0.51 is needed by (installed) crypto-utils-2.1-4.i386 newt is needed by (installed) system-config-mouse-1.2.9-1.noarch newt is needed by (installed) up2date-4.4.50-4.i386 newt is needed by (installed) system-config-network-tui-1.3.22-1.noarch newt >= 0.50.30 is needed by (installed) system-config-printer-0.6.116.4-1.i386 newt is needed by (installed) system-config-date-1.7.15-0.RHEL4.1.noarch newt is needed by (installed) system-switch-mail-0.5.25-3.noarch newt = 0.51.6 is needed by (installed) newt-devel-0.51.6-5.i386 Here's output from rpm -ivh: [root@bd17-napo usr-local]# rpm -ivh snack-2.1.1-2.AWIPS.OB7.i686.rpm Preparing... ########################################### [100%] 1:snack ########################################### [100%] [root@bd17-napo usr-local]# So, rpm -Uvh fails, but rpm -ivh works. QUESTIONS: 1) what does the newt package have to do with the installation of my own snack package? why does RPM think there's a dependency? THERE SHOULD NOT BE ANY. 2) why does rpm -Uvh fail, but rpm -ivh work? The output from rpm -Uvh is exactly what you get when you execute "rpm -e newt-0.51.6-5". I think the problem is that the newt package has a snack module as part of its payload and "snack" is considered to be a "provided capability" (although not a *package*). In general, when rpm -Uvh is issued, an earlier version of that package is removed from the system. In this case, RPM apparently searched its database, found a reference to "snack" (associated with the newt package), and tried to remove the newt package as part of the RPM uninstall phase. This is clearly broken. RHEL4u2 does NOT have the snack package installed. So, why is it trying to remove newt? We have seen this problem on two independent installations of RHEL4u2 (two different machines). RPM appears to be broken in terms of how it's referencing or storing package names and confusing these names with "provided capabilities" (i.e., newt "provides" a snack "capability", but RHEL4u2 does not have the snack "package" installed). I am convinced that you will see this problem by creating an arbitrary "snack" rpm --- doesn't matter how you create the rpm. Just the fact that the package name for the rpm is "snack" will expose this bug when you try installing using -Uvh on RHEL4u2. Thanks. Jim Williams james.d.williams@noaa.gov Actual results: Expected results: rpm -Uvh of a snack package will fail with "newt" dependencies. rpm -ivh of the same snack package will succeed. Additional info:
Please give me the output of: rpm -qp --provides snack-2.1.1-2.AWIPS.OB7.i686.rpm rpm -q --provides newt
[root@bd17-napo usr-local]# rpm -qp --provides snack-2.1.1-2.AWIPS.OB7.i686.rpm snack = 2.1.1-2.AWIPS.OB7 [root@bd17-napo usr-local]# rpm -q --provides newt _snackmodule.so libnewt.so.0.51 snack newt = 0.51.6-5 [root@bd17-napo usr-local]#
Can you attach your spec file for snack and also attach seperately (or paste in) the output of rpm -Uvv snack-2.1.1-2.AWIPS.OB7.i686.rpm
newt provides snack unversioned, which matches against your snack package in upgrade as Upgrades match on all provides not just name provides. Thus it is marked for erasure as nversioned provides match all provides search, thus rpm complains it can't remove newt due to unsatisfied provides in the new package. rpm -i install doesn't remove old versions, so works. Really the best thing to do is grab the newt src.rpm and update snack in there and build that, incrementing release to say 5.0.custom.1 (to allow errata to update)- also please note that you are strongly encouraged to build rpms properly and not just tar up binaries - it's really not that much harder and provides reproducible builds.
I was afraid that something like this might be suggested. While packaging tarballs as rpms may not be ideal, it's also not ideal for us to take a RHEL rpm which we otherwise don't care about and build in a capability which can really stand on its own (snack). It's arbitrary to build snack into newt -- besides you're providing a python interface when we want the tcl/tk interface. I would recommend updating or more clearly defining what is meant by "rpm -Uvh" -- the man page explicitly states that -U "...is the same as install, except all other version(s) of the package are removed after the new package is installed...". It says nothing about "provided capabilities". It's talking strictly about "versions of the package". I will also add that this problem reared its head on only our snack rpm --- we have dozens of others that have not shown this problem. I see this problem as arising more from an arbitrary decision by RH to integrate snack into newt. Why was that done? What is the logic?
The upgrade behaviour is documented clearly in latest RHEL rpm packages in a README.upgrades. The rpm behaviour to match against all provides was a design decision and introduced in all rpm versions since 4.1. I can not answer for the snack/newt issue. It is probably best to take that up via support as documented on the front bugzilla page: Bugzilla is not an avenue for technical assistance or support, but simply a bug tracking system. If you are a Red Hat Enterprise Linux customer and have an active support entitlement, please log in to Red Hat Support: https://www.redhat.com/apps/support/
This bit me too. Even if this is not an RPM problem (it's a "feature" not a "bug?") ... It seems like the Red Hat version of *newt* should be corrected, by Red Hat. Building a custom Newt to get around ambiguity in the capabilities seems like a dead end. If Newt is later updated by Red Hat and hasn't fixed the generic "snack" capability, it will affect me next time I try to upgrade the snack RPM.
Reassign to newt
In rawhide, newt should provide versioned snack. I cannot tell if this helps in your particular situation, but i can't seem to have much more ideas on how to improve situation. If this does not fix your problem, please come back and reopen the report. morn@nev-fcdevel/k3:~/dev/fcdevel/newt -> rpm -qp --provides ./i386/newt-0.52.2-3.i386.rpm _snackmodule.so libnewt.so.0.52 libnewt.so.0.52(NEWT_0.52) snack = 0.52.2 newt = 0.52.2-3