| Pete Zaitcev ( @ 2008-01-29 21:39:00 |
On one box, every run of yum update was complaining about something unavailable around libsilc... I wrote it down to mirror inconsistency and worked around with --exclude. Today I decided to look into it closer, and saw the following:
[root@simbelmyne zaitcev]# rpm -q pidgin fedora-release
pidgin-2.0.0-0.34.beta7devel.fc7.x86_64
fedora-release-8.90-3.noarch
[root@simbelmyne zaitcev]# yum update pidgin
Setting up Update Process
Could not find update match for pidgin
No Packages marked for Update
[root@simbelmyne zaitcev]#
An F7 package has no update when we're builing F9? [*]
[root@simbelmyne zaitcev]# rpm -q --queryformat "%{epoch}\\n" pidgin
2
[root@simbelmyne zaitcev]#
Suddenly the problem came into focus. The worst part of it, current pidgin is version 2.3.1, which is greater than 2.0.0. They could've kept epoch forever and nobody would've noticed... The changelog explains:
* Sat Apr 21 2007 Warren Togami <wtogami@redhat.com> 2.0.0-0.35.beta7devel
- upstream insists that we remove the Epoch
rawhide users might need to use --oldpackage once to upgrade
- remove mono and howl cruft
* Wed Jul 12 2006 Jesse Keating <jkeating@redhat.com> 2:2.0.0-0.6.beta3.1
- rebuild
Hmm... Not sure why "upstream" cares, but whatever.
Just for fun I ran rpm|grep|wc and found a ton of packages with non-empty Epoch. Epoch 0: 108 packages, Epoch 1: 79, other values: 52. The biggest number has aspell-en: Epoch 50! The changelog is:
* Wed Aug 11 2004 Adrian Havill <havill@redhat.com> 50:0.51-9
- sync epoch with other aspell dicts, upgrade to 0.51-1
Now that must be a pretty funny story, but I don't want to know.
[*] Actually we have a few packages from F7 which weren't rebuilt across the whole Fedora 8 cycle, for example grep.