My thoughts on repotag
Michael Schwendt
mschwendt.tmp0701.nospam at arcor.de
Mon Mar 19 14:04:28 UTC 2007
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.
More information about the epel-devel-list
mailing list