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

[Axel Thimm]

On Mon, Jun 05, 2006 at 12:54:44AM +0200, Dag Wieers wrote:
> 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.

Well, strictly speaking, yes. :)

Still let me call the previous implementation utterly broken to the
level of a braintwist, consider the brokenness in the concept back
then. :)

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

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

> 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? :)
-- 
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/20060605/24987ff5/attachment-0003.pgp>