Uncovered by the upgrade path checker script, koffice has a broken upgrade path from FC3 legacy to FC4+ Extras: koffice: 3: 4:1.4.2-0.FC3.2 (FL3-updates) 4: 0:1.5.1-1.fc4 (FE4) 5: 0:1.5.1-1.fc5 (FE5) 6: 0:1.5.1-1.fc6 (FE6) Note the Epoch in legacy.
from koffice.spec (FC4,FC5,devel): %package suite Summary: A free, integrated office suite for KDE Group: Applications/Productivity Obsoletes: koffice <= 4:%{version}-%{release} Obsoletes: koffice-i18n < 4:%{version}
Doh, I knew that examining source packages only has its limitations, but koffice appears to be the only package that currently triggers a false positive because of that. Sorry about the noise, will try to work around in the upgrade checker script.
No worries ;) better to have this here on a false positive then the other way around.
Ok... %package suite Summary: A free, integrated office suite for KDE Group: Applications/Productivity Obsoletes: koffice <= 4:%{version}-%{release} Obsoletes: koffice-i18n < 4:%{version} So this nomenclature looks weird to me. My understanding is that epoch takes priority over packages versions-releases -- so that "product-0:9.9.9-1.2.3" would naturally upgrade to "product-1:1.0.1-0.0.0". If that is so ... then if you are obsoleting koffice <= 4:%{version}-%{release}, but all the FC4, FC5, rawhide versions of koffice are now at epoch 0, then it won't matter at all *what* version you're upgrading koffice to, will it? IN other words, unless I completely misunderstand how RPM specification files work, it looks to me like this kind of "Obsoletes:" nomenclature would have the effect of allowing one to have a binary built from this spec: Name: koffice Version: 1.5.1 Release: 1.fc5 ... Obsoletes: koffice <= 4:%{version}-%{release} Obsoletes: koffice-i18n < 4:%{version} to be "upgraded" (# rpm -Uvh) with a binary built from this spec: Name: koffice Version: 1.4.2 Release: 2.fc4 ... Obsoletes: koffice <= 4:%{version}-%{release} Obsoletes: koffice-i18n < 4:%{version} Can someone try this and prove me wrong?
You're right, but missing the point that in FE4, FE5 or FEdevel there is no *binary* package with the name koffice (they're koffice-suite, koffice-core, ...). I missed that initially too.
No, wrong. That's an impossible upgrade. As soon as koffice-1.5.1-1.fc5 is installed, it also obsoletes koffice-1.4.2-2.fc4 and is seen as newer. Note that it "Obsoletes: koffice <= 4:1.5.1-1.fc5", so EVR of a package MUST be newer than that in order to be a valid upgrade. But nevertheless, doing things like this with Epoch is ugly and nasty.