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