Bug 195815 - koffice: broken upgrade path from legacy to extras
koffice: broken upgrade path from legacy to extras
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: koffice (Show other bugs)
5
All Linux
medium Severity medium
: ---
: ---
Assigned To: Andreas Bierfert
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-06-18 03:34 EDT by Ville Skyttä
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-06-18 03:58:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ville Skyttä 2006-06-18 03:34:24 EDT
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.
Comment 1 Andreas Bierfert 2006-06-18 03:58:57 EDT
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}
Comment 2 Ville Skyttä 2006-06-18 05:49:35 EDT
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.
Comment 3 Andreas Bierfert 2006-06-18 05:55:41 EDT
No worries ;) better to have this here on a false positive then the other way
around.
Comment 4 David Eisenstein 2006-06-18 12:26:34 EDT
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?
Comment 5 Ville Skyttä 2006-06-18 12:59:56 EDT
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.
Comment 6 Michael Schwendt 2006-06-18 14:25:48 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.