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

[Panu Matilainen]

On Mon, 2006-06-05 at 01:56 +0200, Dag Wieers wrote:
> On Mon, 5 Jun 2006, Axel Thimm wrote:
> 
> > On Mon, Jun 05, 2006 at 12:54:44AM +0200, Dag Wieers wrote:
> > > On Mon, 5 Jun 2006, Axel Thimm wrote:
> > 
> > > The problem is introduced when mixing packages that have the old behaviour 
> > > (basicly all core packages) and the newer RPM version that expects 'more'.
> > 
> > No, newer rpm still supports promoteepoch, otherwise a fix in apt
> > wouldn't really make a difference. I didn't have an issue with newer
> > rpm, only newer apt which was accidentilly turning off promoteepoch :)

To be exact, it didn't turn off promoteepoch, the
repomd-zero-epoch-craziness broke promoteepoch :)

> 
> But if there was another way for apt to determine that the system was an 
> RPM < 4.2.1 running an rpm >= 4.2.1, promoteepoch could work 
> transparently. Couldn't the redhat-release RPM header be used to see what 
> RPM was used to build it (or something like that).

It should be possible to write a Lua plugin for determining whether
promoteepoch is needed based on redhat-release or something.. but you
only need promoteepoch if you update rpm itself. Apt itself behaves the
way rpm itself does, epoch promotion for rpm < 4.2.1 and without it for
newer by default.

> > > > W/o "promoteepoch" the set of vendor packages and interdependencies of
> > > > these distros is broken. So for installing some of the vendor's
> > > > packages either in releases or updates, your package managing system
> > > > needs to know about how promoteepoch was working back then.
> > > >
> > > > If you're lucky maybe the chroots you set-up never pull in such
> > > > combinations, and in fact RHEL3 while still tagged as "promoteepoch"
> > > > was the first distro to have the broken dependencies cleansed, but
> > > > promoteepoch in rpm was still in place in case it wasn't properly
> > > > done.
> > > 
> > > Well, I don't think there is a problem if I build my packages on the 
> > > original system with the original RPM.
> > 
> > Of course not. But I thought your systems were living in chroots
> > hosted on a newer system driven by a newer rpm. So if you need to
> > externally populate the chroots then your external tools need to know
> > about the broken^Wdifferent implementation of the evr handling within
> > the chroot.
> > 
> > Maybe your buildsystem is using an internal apt, in which case it is
> > totally isolated from the external system wrt package bits. That would
> > save your day, and make it rather unique under all other buildsystems
> > (in a positive way).
> 
> Yes, that's what I'm doing. I never use the RPM from the host (except for 
> initdb), the chroots do all the work. For that of course I bind-mount 
> whatever is necessary inside the chroot, which makes all the chroots 
> almost identical for the RPM building directory structure.

Right, that way, as you're not updating rpm itself for those older
distros, you don't need to mess around with promoteepoch.

> > > I don't think it has anything to do with being lucky. I'm just
> > > playing according the rules that existed back then. We didn't have
> > > any problems with epochs in those days.
> > 
> > You weren't running on a host teleported back from the future, right? ;)
> > 
> > Anyway to cut a long story short: It's fixed, and you never saw it
> > break (maybe because your buildsystem is better isolated than all
> > others or because you never encountered such vendor package
> > dependencies). What do we really care about it anymore? :)
> 
> Nope, but I needed to understand when the promoteepoch is required. I've 
> seen 2 cases by users where something broke and they've been use 
> promoteepoch since ever. (on newer Fedora systems) and with the new apt it 
> suddenly failed to work, while without promoteepoch it did still work.
> 
> My opinion was that the promoteepoch was wrong in the first place (but why 
> then did it work with it enabled and did it make difference ?)

Again it's the repomd zero epoch madness that broke it, although
promoteepoch is totally unneeded (or even wrong) on FC1 and newer (in
fact RHEL 3 is already clean I think). 

	- Panu -