Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 10743 - RFE: Automatically choosing the RPM with the highest version when upgrading/freshening
Summary: RFE: Automatically choosing the RPM with the highest version when upgrading/f...
Status: CLOSED DUPLICATE of bug 7771
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: rpm
Version: 6.2
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jeff Johnson
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2000-04-12 09:16 UTC by Christian Rose
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Last Closed: 2000-12-28 16:12:39 UTC

Attachments (Terms of Use)

Description Christian Rose 2000-04-12 09:16:53 UTC
Consider that I have this RPM installed on my system:

If I download a bunch of unsorted updates in a directory, among them
and do a "rpm -Fvh *.rpm", rpm will complain that the already installed
gnome-applets-1.1.8-0_helix_2.i386.rpm is newer than
gnome-applets-1.1.8-0_helix_1.i386.rpm, and then exit, not installing the
It would be convenient if rpm would recognize that among those rpm:s given
on the command line was a gnome-applets rpm with a higher version number,
and match that one against the gnome-applets rpm already installed on the
system, instead of matching just the first gnome-applets rpm it finds when
parsing the input rpm:s. In the example above, it would just ignore the
gnome-applets-1.1.8-0_helix_1.i386.rpm, and match the
gnome-applets-1.1.8-0_helix_3.i386.rpm (since it has the highest version
number of the gnome-applet rpm:s on the command line) against the system's
gnome-applets rpm, and in this case, install it, since it has a higher

As it is, I have to manually erase all package duplicates before letting
rpm taking care of the updating. This is especially annoying since some
distros (Helix Gnome) keeps old rpm:s of packages lying around in the ftp
download directory. This is because they have to take into account that
some mirrors that aren't updated may still be linking to those old
packages. But this, together with rpm:s behavior, unfortunately makes "bulk
rpm updates" a very annoying procedure.

Comment 1 Jeff Johnson 2000-08-07 13:42:20 UTC
This problem will be addressed after rpm-4.0 is released.

Comment 2 Gerald Teschl 2000-12-28 16:06:53 UTC
I also think that rpm should handle such cases better. In addition, I think it
should also choose
the "best" arch match, so one can do a

rpm -vF glibc*.rpm

Comment 3 Gerald Teschl 2000-12-28 16:12:36 UTC
Below you can see that there are several tools whose only purpose is
to overcome this defect of rpm. I really think rpm should handle such


       rpmprune - Remove unneeded files from a list of RPM
       package files

       rpmprune [ --newer ] [ --older ] [ --equal ] [ --uninst ]
           [ --invert ] filelist ...

       The rpmprune tool is a simple example of using some of the
       RPM Perl bindings.

       With rpm version 3 and newer, multiple files given on the
       command-line for an install, uninstall or update command
       are treated as a single transaction. If any of the files
       in the set cannot be acted upon, the whole transaction
       must be rejected. This is inconvenient for casual package
       upgrades where a directory may have many rpm files, some
       of which are already installed. A command of:

           rpm -Uhv *.rpm

       would fail, as one (or more) files in the set is already
       installed. This can lead to careless use of options such
       as --force.

       In the simplest usage, this tool eases that situation by

           rpm -Uhv `rpmprune *.rpm`

       When the back-ticks are evaluated, rpmprune has only
       echoed the names of those files that are either newer than
       their installed counterparts, or are not installed at all.

Comment 4 Jeff Johnson 2001-01-09 16:06:40 UTC
Collecting duplcates at bugzilla #7771

*** This bug has been marked as a duplicate of 7771 ***

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