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:16:09AM +0200, Dag Wieers wrote:
> > On Mon, 5 Jun 2006, Axel Thimm wrote:
> > > > I think this might be a promoteepoch handling bug. All these three
> > > > have promoteepoch turned on [and need it turned on :/].
> > > 
> > > just an update: Panu fixed this in r200 (thanks again!), so if anyone
> > > uses apt on any of these distros, you should grab this changeset
> > > (although it is probably only triggered by the presence of a newer
> > > rpm, but if you use apt to manage chroots of elder distros on a newer
> > > system, you're a candidate, too).
> > 
> > I don't have this problem and I don't have to use promoteepoch when using 
> > older distros on a newer system (eg. my buildsystem is EL4, the chroots 
> > are original-rpm el2,rh7,rh9,el3,fc1,fc2,fc3,el4).
> > 
> > I'm a bit confused to who needs to use this promoteepoch configuration 
> > option. Is it possible that it is only required if the packages were made 
> > with rpm < 4.2.1 and the rpm in use is >= 4.2.1 ? (basicly atrpms)
> 
> No, the need to use promoteepoch has not really anything to do with
> ATrpms: The package in these older distros are broken wrt sane epoch
> handling. E.g. the versioned dependencies are not using epochs and
> instead of fixing the packages, the vendor invented "promoteepoch".

You mean the packages in these older distros handle epochs differently.
You can't say that the packages were broken back then, because the 
implementation was different. There was no issue back then because it was 
supposed to be that way.

The problem is introduced when mixing packages that have the old behaviour 
(basicly all core packages) and the newer RPM version that expects 'more'.


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

So promoteepoch is only a problem if you add a newer RPM to a system that 
was designed with a different paradigm. Like atrpms is doing.


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]