Bug 10743

Summary:	RFE: Automatically choosing the RPM with the highest version when upgrading/freshening
Product:	[Retired] Red Hat Linux	Reporter:	Christian Rose <menthos>
Component:	rpm	Assignee:	Jeff Johnson <jbj>
Status:	CLOSED DUPLICATE	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	6.2	Keywords:	FutureFeature
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2000-12-28 16:12:39 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Christian Rose 2000-04-12 09:16:53 UTC

Consider that I have this RPM installed on my system:
gnome-applets-1.1.8-0_helix_2.i386.rpm

If I download a bunch of unsorted updates in a directory, among them
gnome-applets-1.1.8-0_helix_1.i386.rpm
and
gnome-applets-1.1.8-0_helix_3.i386.rpm,
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
updates.
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
version.

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
situations.

From http://www.blackperl.com/Perl-RPM

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

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

DESCRIPTION
       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
       allowing:

           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 ***