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

[Panu Matilainen]

On Sat, 2006-05-27 at 02:21 +0200, Axel Thimm wrote:
> On Fri, May 26, 2006 at 10:48:27PM +0300, Panu Matilainen wrote:
> > In that case the HideZeroEpoch runtime configuration patch in my
> > previous mail would probably help. 
> 
> Shouldn't promoteepoch then automatically trigger the HideZeroEpoch
> patch (e.g. do we really need this as a new config)?

Hmm, it might indeed make sense to link it with promoteepoch. 

> > The situation is really just insane: to support repomd repositories
> > made with unpatched createrepo, to behave consistently with modern
> > rpm which is not supposed to care about zero vs no epoch, we need to
> > strip all the zero epochs everywhere (that's what smart does as
> > well, and the other option of *adding* zero epochs where they don't
> > exist breaks even more things). And to try to support older versions
> > we leave them intact and pray that a patched createrepo was
> > used. It's just sick. And all because of createrepo lies about
> > non-existent epochs. SIGH.
> 
> Can't we just
> 
> o file a bug against createrepo
> o assume createrepo doesn't mess with missing epochs (e.g. is the
>   patched version)
> 
> For newer distributions which also have repomd support there is no
> real issue with zero epoch != no-epoch, because the promoteepoch
> issues were fixed in (or after) RH9/RHEL3. Older distributions didn't
> work with repomd and unpatched creatrepo until now anyway.

The needed change in createrepo breaks both yum and smart, and *still*
we'd need to support the current brokenness anyway, there are far too
many repositories in the world created with zero epochs everywhere. And
because of how apt works internally, we need to accommodate for those
extra zero epochs for somehow (remove everywhere or add everywhere,
adding caused all sorts of other nastiness so removing was selected +
that's what smart does as well for similar reasons).

	- Panu -