[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