My thoughts on repotag

Michael Schwendt mschwendt.tmp0701.nospam at arcor.de
Mon Mar 19 16:21:49 UTC 2007


On Mon, 19 Mar 2007 16:05:10 +0100 (CET), Dag Wieers wrote:

> > > 	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?
> 
> It's a tradeoff that has no effect on release comparison.

It _is_ part of %release. It _is_ added to automatic versioned Provides.
It _is_ added to manual Requires/Obsoletes/Conflicts that use %{release}.
And all that is in addition to %dist, which must be considered in
versioned Requires/Obsoletes/Conflicts already.  Yet what benefit does it
result in?

A tradeoff? Just to give users a questionable way to see whose packages
cause trouble during a yum update?

> The repotag was not intended to influence release comparison.

Nobody has said that this would be its intention. Still it is the
least-significant portion of the package %release.

> The repotag 
> is useful for other reasons and the easiest way to add itr without 
> redesigning RPM is to add it there.

The easier way to add it is to use the Vendor tag and introduce a short
macro with which to query the RPM database. Think repoquery, yum queries,
tools that show the repository/vendor a package comes from.
 
> > Why does the repo with the "highest" tag win over packages with a "lower"
> > tag?
> 
> Because that's how the algorithm was designed to work. But since there is 
> no relation between release of different repositories, it does not matter.

A repository is either made to be 

 a) compatible or
 b) incompatible.

For a) either party can take precautions. For b) one party can make sure
its packages win version comparison. a) is hurt when packages upgrade
eachother just because of a different repotag. For b) there better is the
recommendation to disable the incompatible repos in order to avoid
potential trouble and upgrade races. Especially when upgrades add/remove
features, your users do not like that at all.

> > 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?
> 
> Because they are maintained by different people that have different ideas 
> what goes in and what doesn't. Different set of patches, as close to 
> upstream as possible, whatever.
 
So, incompatible repos. Case closed.

> Functionality like that can only exist if there is a mindset that 
> multiple repository will exist. With Fedora this mindset has been 
> destroyed and as a result the tools do not allow it.

The only form of cooperation and collaboration that exists is added by a
few individuals, who have become Fedora Extras maintainers while
continueing with their private repositories. Nothing else has been
worked on. No guidelines, no policies. Nothing.
 
> Which in its turn killed the diversity. For Fedora Extras that might have 
> been a good thing, but for RHEL that will lead to problems.

RHEL/EPEL must be even more careful about what software and what upstream
releases they decide to ship. Fedora Extras over the past months has
presented several examples of packages, where team-work would have been
much better. EPEL will hopefully evaluate carefully what they include
and how that compares with existing 3rd party repos such as yours.

> > > Add a repotag to both cases for your amusement, it would not matter.
> > 
> > Right. Upgrade race in most-significant portion of %release. Bad.
> 
> You haven't proved that and it doesn't matter anyhow.

".rf" is higher than ".fdr"

1.*.rf  > 1.*.fdr  =>  upgrade
2.*.fdr > 1.*.rf   =>  upgrade
2.*.rf  > 2.*.fdr  =>  upgrade

qed

Either the repos are compatible in that mixing them is not considered a
problem. Or they are designed to be incompatible and error-prone to use,
because even the slightest change in %release causes upgrades.

> Releases from different repositories have no relation. (repeat after me)

Then they ought not be enabled at once.




More information about the epel-devel-list mailing list