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
following:
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.
BUT:
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