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

[Axel Thimm]

On Tue, Aug 08, 2006 at 09:42:48AM +0300, Panu Matilainen wrote:
> > 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.

createrepo -n will break yum and smart support (which ATrpms offers
for these old distros). What's the difference in removing the zero
epochs in the creating of the metadata or dropping them when they are
being read in the depsolver? It's effectively the same and we don't
need to break compatibility with smart/yum.

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

No, it's not about ATrpms, it's the vendor's repos that matter and in
this case there are no zero epochs anywhere. I can't say anything about
other distros but RHL/RHEL/FC, but there the assumption holds.

Maybe have zero-epoch stripping a config option again to address any
possibility of such a repo?

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

Again, what do we care what createrepo did? Simply ignore zero epochs
while they are being parsed (or elsewhere), this is the same as is
createrepo wouldn't had injected them and we remain compatible to
other repomd clients.

> > 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 :-/

But would there be anything wrong in the RHL/RHEL/FC world if
stripping them would always be on? I don't see any case and it has the
benefits of not requiring incompatible repomds.

I can understand that apt shouldn't assume nothing but RHL/RHEL/FC
exists, but perhaps other readers from other distros can confirm that
this is no issue there, too, or we can make that a config option again
to cover any potential issue.
-- 
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/53e70617/attachment-0003.pgp>