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

[Panu Matilainen]

On Tue, 8 Aug 2006, Axel Thimm wrote:

> 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.

Yes, but createrepo injects artificial zero epochs *everywhere*, and 
that's the sole reason for this madness. You need to use createrepo -n 
switch for repositories requiring promoteepoch behavior, that way it 
doesn't add the false epochs.

> 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.

Perhaps in your repositories there are no explicit zero-epoch packages but 
it's not an assumption apt can make generally.

> 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.

For rpm version comparisons it doesn't make any difference in B), but
apt uses the version string (epoch included) internally for a "version 
hash" so it can tell whether package X seen in a repo or rpmdb is exactly 
the same as in another repo. If those don't match, funny things start 
happening, so even with modern distros the epoch's need to be stripped 
everywhere or added everywhere with default createrepo output.

> 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.

In case A) apt can only blindly rely on the repository maintainer to use 
-n option with createrepo, in B) it can and does workaround the repomd 
madness. It's a hideous mess for sure, but what can you do :-/

 	- Panu -