Red Hat Bugzilla – Bug 189308
RFE: Display NEVRA when installing/upgrading packages
Last modified: 2007-11-30 17:07:31 EST
This an SME Server patch - pushing upstream for consideration. The attached
patch shows the name-epoch:version-release.arch of packages being installed or
upgraded. We've found it very useful and hope you do too.
Patch is against anaconda-10.1.1.37-1
The following packages were available in this version but NOT upgraded:
DCC-0:1.3.0-12.el4.at.i386 (already installed)
MAKEDEV-0:3.15-2.i386 (already installed)
acpid-0:1.0.3-2.i386 (already installed)
anacron-0:2.3-32.i386 (already installed)
apmd-1:3.0.2-24.i386 (already installed)
Created attachment 127962 [details]
Display NEVRA when installing/upgrading packages
In the current tree, we display N-V-R.A -- what do you see as the benefit of
adding the epoch?
(In reply to comment #2)
> In the current tree, we display N-V-R.A -- what do you see as the benefit of
> adding the epoch?
We've had a few upgrade cases where someone has forked a package (e.g. to patch
a security issue on an old version) and bumped the Epoch in order to outvote the
main stream. One of our major tasks with the recent SME Server (nee e-smith)
realignment with had been to kill off all of those forks (our problem, not
yours). One example is proftpd which was patched, but we have now moved to the
DAG repository version.
The smaller N-V-R with the bigger Epoch wins over the newer package with the
smaller Epoch. Without the log of the Epoch, the package is "silently" not
upgraded even though the later N-V-R appears to win. This causes a bit of
head-scratching, which is removed once the Epoch is displayed.
The upgrade behaviour is correct, but the addition of the Epoch log makes it
obvious why the choice has been made by anaconda.
Changed for FC6/RHEL5
The patches aren't quite right as they don't differentiate an Epoch of zero from
If we fix that before you do, I'll attach revised patches.
Moving request to RHEL5. PM ACK as it seems to be done there.