[Rpm-metadata] Zero epoch vs no epoch (patch)

Christoph Thiel cthiel at suse.de
Mon May 8 10:38:13 UTC 2006


On Sat, 29 Apr 2006, Panu Matilainen wrote:

> > > > >  - Even if no epoch is specified, the metadata still specifies 
> > > > >    this as "0".  For most code paths this is no problem as for 
> > > > >    all comparisons of version data, a missing epoch is the same 
> > > > >    as a "0"  epoch. This should not be a huge problem and would 
> > > > >    be only a cleanup item for the repodata.
> > > >
> > > > what does removing 0-epoch items buy us?
> > >
> > > What it buys is support for ancient rpm versions. Remember those 
> > > monstrosities where non-existing epoch is not equal to zero epoch, 
> > > epoch promotion and all that fun? I couldn't personally care less 
> > > about the old rpm versions but there are people who do care, for 
> > > example Dag and Matthias: 
> > > http://lists.freshrpms.net/pipermail/freshrpms-list/2006-April/014022.html
> > >
> > > Removing those zero epochs from repodata makes yum rather unhappy, 
> > > dunno about smart, so changing the default is not really a 
> > > possibility. But then neither supports the prehistoric versions that 
> > > are of concern here. Attached quick hack of a patch adds a switch to 
> > > turn off adding those artificial zero epochs, using this as 
> > > necessary this should be enough to allow using repodata with full 
> > > rpm 3.0.x - 4.4.x range.
> >
> > When we were implementing rpm-md support for our online update 
> > channels, we stumbled over the epoch thingy as well, but had to add 
> > the epoch="0", to keep yum & smart intact. The funny thing we found 
> > was the fact that rpm itself doesn't handel an empty epoch 
> > consistently -- if there is any interest, I'll dig into the rpm code 
> > again to give you the details...
> 
> IIRC rpm 4.2.1 was the first version of rpm to handle zero vs no epoch 
> equally and sanely, except for a bug in "freshen" case where it did 
> matter for rpm itself until recently (fixed last year or so). Other than 
> the freshen issue (which didn't affect depsolvers) I'm not aware of any 
> *recent* issues wrt epochs. Before rpm 4.2.1 there was the promote-epoch 
> behavior on by default and whatnot.. a horrid mess especially thinking 
> about it afterwards :)

I just went through the code of rpm 4.4.5 with our RPM maintainer again 
and we found:

rpmVersionCompare (psm.c):
=> no epoch is smaller than epoch 0

rpmdsCompare(rpmds.c)
=> no epoch is equal to epoch 0


Regards
	Christoph



More information about the Rpm-metadata mailing list