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):
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
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
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
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
"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-18.104.22.168-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-22.214.171.124-1.i386
libnewt.so.0.51 is needed by (installed) setuptool-1.17-2.i386
libnewt.so.0.51 is needed by (installed)
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)
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%]
So, rpm -Uvh fails, but rpm -ivh works.
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.
rpm -Uvh of a snack package will fail with "newt" dependencies.
rpm -ivh of the same snack package will succeed.
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
newt = 0.51.6-5
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
If you are a Red Hat Enterprise Linux customer and have an active support
entitlement, please log in to Red Hat 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
snack = 0.52.2
newt = 0.52.2-3