[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: My thoughts on repotag



On Mon, 19 Mar 2007, Michael Schwendt wrote:

> 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?

It's a tradeoff that has no effect on release comparison.

The repotag was not intended to influence release comparison. The repotag 
is useful for other reasons and the easiest way to add itr without 
redesigning RPM is to add it there.

Maybe you can work out with the RPM maintainers to improve it in the 
future. But we discussed this 5 years ago and it hasn't happened yet.

 
> 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.


> 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.



> > > "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.

Sure, but that's up to the user (or hopefully the dep resolver) to decide.

It really is up to whoever decides to use another repository, for whatever 
reason you cannot contain.

And yum, apt, whatever should allow to define a policy. What repository to 
use for what ? Whether to restrict based on (only) version (from that 
repo).

Fact is that if the user specifies to use a package from another 
repository, it only gets updated from that repository unless he overrides 
that behaviour again.

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.

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.

  
> > 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.

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

 
> > 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. :)

Doesn't matter, none of these are intrinsically higher anyway.

 
> > 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.

There is no upgrade race between repositories because there should not be 
an upgrade path. As long as you think that a repotag will be bad for the 
upgrade path between repositories, you assume there is an upgrade path 
between repositories that have packages with the same version.

It's all in your head.

Kind regards,
--   dag wieers,  dag wieers com,  http://dag.wieers.com/   --
[all I want is a warm bed and a kind word and unlimited power]


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]