Start gnorpm, select Install. The page that is displayed should *not* have an Install button, as Upgrade is almost always what is needed. FWIW, here are several other nit-nots 1) If "Expand Tree" is hit immediately, a downrev version of gnorpm is displayed. That means, when running gnrorpm-0.95.1-5, gnorpm-0.95.1-3 is displayed for reasons beyond my ken. 2) "Select All" after "Add" should not select multiple occurences of identically named packages. While filtering multiple identically named packages should have been implemented in rpmlib many moons ago, rpmlib has *never* behaved gracefuully when presented with mutiple identical packages as part of the same transaction, and support for legacy versions of rpm demands the filtering in gnorpm rather than rpmlib.
The install button maybe should prompt with an are you sure to do a '--force' type thing but it is needed in some cases so needs to stay The rpmlib stuff is a mess. I am very tempted to stop using rpmlib and use rpm down pipes in order to escape the disgusting mess it causes. Possibly rpm-at or the redcarpet libs will help. I plan to drop support for rpmlib 2.x before gnorpm 1.0, does 3.x have this problem too ?
No --force is not the answer. Presenting a single choice "Upgrade" (which is identical to "Install" if package is not already imstalled) was the suggestion, as otherwise you will have to entries in the database for the same package. FWIW, proper bug reports against rpm will start to resolve the "mess", as I can't change nothing without a request.
I moved this bug to the gnome bugzilla so that the Gnorpm maintainers gets a look at it. It is now at: http://bugzilla.gnome.org/show_bug.cgi?id=58175