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 /root/{install,upgrade}.log shows: [...] Upgrading e-smith-email-0:4.15.4-17.noarch Upgrading e-smith-pop3-0:1.1.0-03.noarch Upgrading smeserver-spamassassin-0:1.3.0-06.noarch Upgrading comps-2:4.2CENTOS-0.20051011.i386 Upgrading comps-0:4.1SMEServer-0.20050914.i386 The following packages were available in this version but NOT upgraded: DCC-0:1.3.0-12.el4.at.i386 (already installed) LPRng-0:3.8.28-2.i386 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
Hi there, The patches aren't quite right as they don't differentiate an Epoch of zero from no Epoch: http://www.contribs.org/bugzilla/show_bug.cgi?id=1423 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.