Fedora Project launches Pre-Extras

Michael Schwendt fedora at wir-sind-cool.org
Sat Dec 18 23:03:34 UTC 2004


On Sat, 18 Dec 2004 23:36:58 +0100 (CET), Dag Wieers wrote:

> > Well, it doesn't make much sense to discuss this further or to pound
> > on obvious examples. Since for inter-repository dependencies, I'm an
> > advocate of the "determine overlapping contents and move them into a
> > common base repository" methodology. Alternatively, replicating common
> > packages with exactly the same NEVR (and preferably, built in the same
> > environment) would be another solution.
> 
> Please give me an example where it influences the RPM version comparison 
> in a *relevant* way ? You, Seth and Jeff are spreading this fable and it 
> is the only argument I heard to get rid of it.
>
> All the obvious examples are broken, even without repotag or disttag there 
> is no important reason why release 2 from one repo should be upgrade to 
> release 3 of another repo.

Why should release 2 from one repo upgrade release 2 from a different
repo?

What is the relationship between those two releases anyway?

If we're in the namespace of a _single_ repo, we don't need repo tags
and we don't need dist tags either. Repo tags don't add any value if
there is no global registry which assigns unambiguous repo tags to
package vendors. Dist tags influence RPM version comparison even more
than repo tags, because they are commonly used to ensure a sane
upgrade path: rh73 < rh80 < rh9 and then? rh9 > fc1. No wait, somebody
even suggested to continue with rhfc1 or something which is "bigger
than" rh9, just to please the dist tag versioning scheme. Please let
us not return to such discussions.

The arguments for repo tags or dist tags don't convince me. In particular
not, when I read that users can build trust into package files based
on a substring of the filename, and at the same time the .fdr tag,
which is used by more than one package vendor, is called a poor choice.

This is a dead end. Let's move forward.




More information about the fedora-test-list mailing list