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

[Dag Wieers]

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 :)

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


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


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

I guess he was bitten by this bug and the wrong config.

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]