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

Axel Thimm Axel.Thimm at ATrpms.net
Sat May 27 02:23:30 PDT 2006


On Sat, May 27, 2006 at 11:55:30AM +0300, Panu Matilainen wrote:
> 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).

Was there ever a situation where it was *designed* to have zero and
non-epochs compared? Can't we live on the safe side assuming that zero
epoch=no-epoch (BTW this was the trick to fix fedora.us's mass
zero-epoch introduction back then: apt just had to assume zero=none to
get the universe in line again)?

For rpm >= <someversion> this is already true, and for the time before
that the zero-epoch > no-epoch was simply an unnoticed bug, noone
really built upon this "feature". Or did something really ever depend
on zero-epoch > no-epoch? Maybe it only kills us in combination with
promoteepoch mode (another great "feature" of the past ...)?
-- 
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/20060527/04f024fb/attachment-0003.pgp>


More information about the Apt-Rpm mailing list