My thoughts on repotag
Dag Wieers
dag at wieers.com
Mon Mar 19 13:37:38 UTC 2007
On Mon, 19 Mar 2007, Michael Schwendt wrote:
> On Mon, 19 Mar 2007 13:50:05 +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
> >
> > Then you assume that minor numbers are behind the repotag, which is a bad
> > implementation.
>
> Funnily, that implementation is used by Fedora and has worked well.
Do you always work with circular logic ?
What you give as an example would not work in a multi-repository world,
which is what we are discussing and which is WHY we ask for a repotag.
Take away the miltu-repository world and you can put whatever you want in
your release-tag or your version comparison and it wouldn't matter.
So if you are looking for self-serving examples that go beyond what we are
discussing, please do not reply to my emails.
> 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.
So it might as well improve the version comparison :) It all depends what
the user wanted, the system doesn't know.
> > > In the past, the proponents of mandatory dist tags have ignored that issue
> > > or have tried to fight it with their main counter-argument that updates
> > > are applied to all branches always. Mass-updates *always*.
> > >
> > > As I've explained before, more tags at the right of %release don't solve
> > > the repository mixing problems.
> >
> > But it doesn't affect it either. The example you gave was a bad example.
> > disttags and repotags are at the far right.
>
> "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
Add a repotag to both cases for your amusement, it would not matter.
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. The two first examples are more common then the latter example
(which is yours) and in none of the cases there is a real difference.
Summary: there is no defined way which one should come out on top
Kind regards,
-- dag wieers, dag at wieers.com, http://dag.wieers.com/ --
[all I want is a warm bed and a kind word and unlimited power]
More information about the epel-devel-list
mailing list