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.