My thoughts on repotag

[Michael Schwendt]

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

> > The least-significant portion of %release however is blocked by and abused by
> > a dist tag and a repo tag.
> 
> No, it doesn't make the version comparison any more better or worse. Again 
> I repeat myself, read it slowly and please think:
> 
> 	Comparing release tags for packages from different repositories 
> 	(with or without a repotag) makes no sense because there is *no* 
> 	relation.

Then why is the repotag included in the version comparison?

Why does the repo with the "highest" tag win over packages with a "lower"
tag?

Why do foo-1.0-1.el4.epel.i386.rpm and foo-1.0-1.el4.blubb.i386.rpm differ
in what they contain, what features they offer, how they are patched.
even though the package release differs only in a repo tag?

> > "Highest" repo tag does win RPM version comparison.
> 
> There is nothing to win. If you don't add a repotag and you get these 2:
> 
> 	nagios-2.8-2.el5	from EPEL
> 	nagios-2.8-3.el5	from RPMforge
> 
> What does that mean ? It may be as problematic as the case where:
> 
> 	nagios-2.8-3.el5	from EPEL
> 	nagios-2.8-2.el5	from RPMforge

Right. If the two repositories don't collaborate, it can be bad indeed.
The 3.el5 release may be worse than the 2.el5 release or vice versa.
 
> Add a repotag to both cases for your amusement, it would not matter.

Right. Upgrade race in most-significant portion of %release. Bad.

> Now consider:
> 
> 	nagios-2.8-2.el5	from EPEL
> 	nagios-2.8-2.el5	from RPMforge
> 
> And in all cases, where it is questionable which one *should* have been 
> taken.

Right. Upgrade race. I repeat myself. :)

> Summary: there is no defined way which one should come out on top

Right, that's why the added repo tag already wins. Upgrade race part #1.
Bad. Upgrade part #2 is when 3rd party repos bump release everytime they
want to win version comparison always.