0.5.15lorg3.1 loses epochs on rh7.3/rh8.0/rh9 (promoteepoch?)

Axel Thimm Axel.Thimm at ATrpms.net
Mon Aug 7 17:40:35 PDT 2006

On Tue, Aug 08, 2006 at 02:10:16AM +0200, Axel Thimm wrote:
> Hi,
> On Mon, Jun 05, 2006 at 12:09:49AM +0200, Axel Thimm wrote:
> > On Fri, May 26, 2006 at 08:32:07PM +0200, Axel Thimm wrote:
> > > The following packages have unmet dependencies:
> > >   rpm-build.32bit: Depends: perl (>= 5.006001)
> > > 
> > > rpm-build requires 5.006001 and perl offers 1:5.6.1-36.1.73, so it
> > > looks like the epoch was dropped.
> > > 
> > > I think this might be a promoteepoch handling bug. All these three
> > > have promoteepoch turned on [and need it turned on :/].
> > 
> > just an update: Panu fixed this in r200 (thanks again!), so if anyone
> > uses apt on any of these distros, you should grab this changeset
> > (although it is probably only triggered by the presence of a newer
> > rpm, but if you use apt to manage chroots of elder distros on a newer
> > system, you're a candidate, too).
> I now switched from using apt-rpm metadata to repomd. Suddenly
> promoteepoch is broken again. Unepoched dependencies get a 0 epoch
> inserted instead of promoting the epoch. Switching back to apt-rpm
> metadata fixes the issue again.

OK, I checked the code and the archives and it all revolves around the

	    Why is HideZeroEpoch ever different from "true"?

There are two cases:

A) We live in the promoteepoch world
   In this prehistoric time it was unceivable that a package would
   have an epoch of "0". A missing epoch was indeed a missing epoch
   and nothing more or less. Unepoched dependencies and
   rpm-comparisons had a sick algorithm which depended on the package
   being installed or not.


   There were no explicit zero-epoch packages, neither were there
   explicit zero-epoch in dependencies.

B) The modern times
   promoteepoch was considered evil and the distributions fixed not to
   depend on it. Even rpm was fixed to equal in comparisons no-epoch
   to zero-epoch. But one day someone had the great idea to shove
   zero-epochs everywhere. It doesn't serve any special purpose and
   this idiom is being slowly abandoned to meet its cousing
   "promoteepoch" soon.

   Therefore explicit zero-epochs are nonsense and can be discarded.

If we strip zero-epochs out of everything shouldn't we be fine?

In case A) there weren't ever any explicit zero-epoch packages, so
whatever repomd says, when --promotepeoch is used, we can assume that
the zepo-epochs can be discarded.

In case B) we don't need the promoteepoch mechanism anymore and
explit zero-epochs are redundant. Which means that whether we hide
zero epochs or not should not make any difference.

Currently apt choses to *not* strip zero epochs from case A) which
seems like a bug, and to strip them from case B) which doesn't
matter. It should be either the opposite or stripping them for all.
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.laiskiainen.org/pipermail/apt-rpm-laiskiainen.org/attachments/20060808/dcb918c8/attachment-0003.pgp>

More information about the Apt-Rpm mailing list