Bug 171415 - rpm -Uvh of custom snack package fails, but rpm -ivh succeeds on RHEL4u2
rpm -Uvh of custom snack package fails, but rpm -ivh succeeds on RHEL4u2
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: newt (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Petr Rockai
Jay Turner
Depends On:
  Show dependency treegraph
Reported: 2005-10-21 12:10 EDT by jim williams
Modified: 2015-01-07 19:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-01-17 04:41:47 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description jim williams 2005-10-21 12:10:57 EDT
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):

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):
  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".
  "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-
        libnewt.so.0.51 is needed by (installed) netconfig-0.8.21-1.1.i386
        libnewt.so.0.51 is needed by (installed) ntsysv-
        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%]
[root@bd17-napo usr-local]#
  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?

   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.

 Jim Williams

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:
Comment 1 Paul Nasrat 2005-10-21 13:04:12 EDT
Please give me the output of:

rpm -qp --provides snack-2.1.1-2.AWIPS.OB7.i686.rpm
rpm -q --provides newt
Comment 2 jim williams 2005-10-21 13:29:59 EDT
[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
[root@bd17-napo usr-local]#
Comment 3 Paul Nasrat 2005-10-21 13:50:51 EDT
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
Comment 4 Paul Nasrat 2005-10-21 14:04:34 EDT
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.
Comment 5 jim williams 2005-10-21 14:17:05 EDT
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?
Comment 6 Paul Nasrat 2005-10-21 14:31:07 EDT
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:

Comment 7 Brian McEntire 2005-10-21 14:44:48 EDT
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.
Comment 8 Paul Nasrat 2005-10-21 15:18:22 EDT
Reassign to newt
Comment 9 Petr Rockai 2006-01-17 04:41:47 EST
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 
snack = 0.52.2 
newt = 0.52.2-3 

Note You need to log in before you can comment on or make changes to this bug.