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.