Re: Zero epoch vs no epoch (patch)
Christoph Thiel <[email protected]>
| Newsgroups | gmane.linux.rpm.metadata |
|---|---|
| Message-ID | <[email protected]> |
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