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

Panu Matilainen pmatilai at laiskiainen.org
Wed Aug 9 08:14:53 PDT 2006


On Tue, 2006-08-08 at 12:49 +0200, Axel Thimm wrote:
> On Tue, Aug 08, 2006 at 12:36:36PM +0200, Dag Wieers wrote:
> > 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
> 
> OK, as written elsewhere, now my brains spins in the right direction,
> too.
> 
> Maybe I'll just remove yum & smart for older releases (e.g. everything
> before RHEL3/FC1), I want to EOL these distros till the end of the
> year anyway.

Actually I'm curious how the heck yum & smart manage to work on those
older releases? In case of yum .. it might be explainable by the facts
that
a) It doesn't check for full dependency closure so rare corner cases
like the one here could easily go hidden for a long time:
http://lists.laiskiainen.org/pipermail/apt-rpm-laiskiainen.org/2006-April/000071.html b) Since it downloads the rpm headers, it ends up giving rpmlib untampered dependency info, with rpmlib of course can handle.

Smart is the big mystery here: AFAIK it also checks full dependency
closure, only uses repodata and no headers and works very similarly to
apt in many other ways as well. If Smart can *really* handle those old
distros then apt should be able to do so as well. But from what I've
looked at smart's code, it does the very same 'remove all zero epochs,
everywhere' as apt-rpm does (only smart doesn't have any logic to stop
it from doing that) and thus should suffer from the same issues as apt
has (in the thread referred to above).

> > 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.
> 
> OK.
> 
> > 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.
> 
> Well, even impossible, so there isn't much to choose :)
> 
> I tend to letting the issue die. I think that working with upstream to
> fix createrepo/yum will take too much energy since upstream isn't
> interested in these distros anymore since long.

That'd be my advice as well. I find it highly unlikely that neither Seth
or Gustavo are interested in fixing things for dying distros at this
point, never mind changing the defaults of createrepo. I'd rather see
the pain handled where the pain is - in other words the old
distributions - without inflicting incompatible changes to the rest of
the world which is not even affected by this whole thing.

One thing I *would* welcome is having some kind of flag in the repomd
data to detect if the repo was created with -n or not so clients would
have the option to ignore incompatible repositories. However my
suggestion on doing that was received with a great wall of silence:
https://lists.dulug.duke.edu/pipermail/rpm-metadata/2006-April/000631.html

	- Panu -

	- Panu -




More information about the Apt-Rpm mailing list