My thoughts on repotag

[Michael Schwendt]

On Mon, 19 Mar 2007 14:44:00 +0100 (CET), Dag Wieers wrote:

> > > > It still fails for branch-specific (i.e. dist-specific) fixes, where the
> > > > least-significant portion of the full %release value is increased for
> > > > rebuilds or minor fixes:
> > > >
> > > > 	foo-1.0.0-2.el5.fdr.1 < foo-1.0.0-2.el5.rf
> > > 
> > > but foo-1.0.0-2.el5.fdr < foo-1.0.0-2.el5.rf so it wouldnt be installed in 
> > > the first place if you had those repos configured ...
> > 
> > And that is flawed.
> > 
> > The package release string gets longer without telling anything about
> > which of the packages is newer. Anyone still want to claim that these tags
> > don't influence RPM version comparison? ;) Packagers would be forced to
> > increment the most-significant part of %release, breaking the dist-upgrade
> > path,
> > 
> >     foo-1.0.0-3.el4.fdr > foo-1.0.0-2.el5.fdr
> > 
> > unless superfluous mass-updates and mass-rebuilds are used.
> 
> Once again a self-serving example, it has nothing to do with repotags.
> 
> 	foo-1.0.0-3.el4 > foo-1.0.0-2.el5
> 
> I'm sure you could have come up with this:
> 
> 	foo-1.0.0-2.el4.1.fdr < foo-1.0.0-2.el5.0.fdr
> 
> Which is exactly how it used to be without the repotag. I can only see bad 
> intent in the form of your examples.

Do you realise that now you've gone as far as comparing a release digit
with a repo tag?

2.el4.1 wins over all 2.el4.somerepotag

Version comparison hell. Upgrade race. Again and again.