Some Fedora 12 packages have versions that do not supersede the versions of Fedora 11 packages, preventing a complete upgrade to FC12. A partial list is: tigervnc-1.0.0-2.fc11.i586 gst-mixer-2.26.0-3.fc11.i586 libotf-0.9.9-3.fc11.i586 nautilus-cd-burner-libs-2.25.3-7.fc11.i586 lame-libs-3.98.2-3.fc11.i586 iptstate-2.2.2-3.fc11.i586 kmodtool-1-18.fc11.noarch preupgrade-1.1.2-1.fc11.noarch parrot-docs-1.6.0-2.fc11.noarch mod_dnssd-0.6-2.fc11.i586 libnetfilter_conntrack-0.0.100-1.fc11.i586 a52dec-0.7.4-15.fc11.i586 faad2-libs-2.7-1.fc11.i586 libvolume_id-141-7.fc11.i586 twolame-libs-0.3.12-4.fc11.i586 parrot-1.6.0-2.fc11.i586 parrot-devel-1.6.0-2.fc11.i586 parrot-tools-1.6.0-2.fc11.i586 faac-1.28-1.fc11.1.i586 iw-0.9.17-3.fc11.i586 sos-1.8-17.fc11.noarch gnome-mount-0.8-5.fc11.i586 For example, 'yum update iw' does nothing; 'yum install iw' results in an error message Transaction Check Error: package iw-0.9.17-3.fc11.i586 (which is newer than iw-0.9.17-2.fc12.i686) is already installed Similar behavior for all other packages on the list.
Package review component is for reviewing NEW packages not in the repository yet. Please post to fedora-devel list instead.
Package review component is for reviewing NEW packages not in the repository yet. Please post to fedora-devel list instead. OK, I had no idea where to put this report---it's a packaging system issue as much as a specific package issue so I went by a name that seemed plausible, in absence of better information on what the components actually cover. Look, I was trying to do the right thing. Can't you help me by suggesting a Bugzilla component/category that this belongs in, instead of dismissing this to some mailing list? I think it'd be better if this gets captured in the regular workflow. You closed the issue with status NOTABUG which implies that it is fixed but it is not, and if unsolved it could eventually affect RHEL customers upgrading from previous versions. If there isn't any existing category, it should be created, in my opinion---the alternative being to report umpteen package versioning issues against the individual packages in question.
I suggested what I thought was the quickest path. If you want to do it properly, individual bug reports against each of the components would be the way to go. Catch all components are not useful since each package is maintained by a different person.
There's a "distribution" component that is far, far more appropriate than "Package Review".
Changed to 'distribution' component per Jason Tibbitts' comment #4