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

[Dag Wieers]

On Tue, 8 Aug 2006, Axel Thimm wrote:

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

The problem is currently Smart and Yum. They expect zero epoch (at 
least) everywhere and do not support a (none) epoch and this is required 
for older releases.

Axel, the only way that my repomd repository will work with your Smart and 
Yum for older releases is if Smart and YumÃmget fixed

I have to use createrepo -n on older releases and I'm thinking of using it 
for new releases as well as (and do the same with Yam). If Yum and Smart 
fail, this is something to be fixed in Yum and Smart and if those are 
fixed, maybe we can move on and make -n the default.

It's an oversight in the repomd format and we have to fix that to make the 
situation normal and understandable again.

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

What we want to avoid is having yet another interpretation level in the 
client just to accomodate a broken (or rather unsupported) implementation.
Let's keep the repomd synchronised with the real metadata and fix the 
client.

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

We do care what createrepo did, as we have to use the metadata. And if the 
metadata is obviously incorrect we have to fix that. If that means that 
certain clients do not understand those changes, they have to be updated 
as well.

Because the issue is here that Yum and Smart are not designed to work with 
older releases (none-epoch) and that has to be fixed. Every other 
work-around is making things even more ugly.

Kind regards,
--   dag wieers,  dag at wieers.com,  http://dag.wieers.com/   --
[all I want is a warm bed and a kind word and unlimited power]