On Sunday 19 December 2004 00:03, Michael Schwendt wrote: > 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? That depends. If you're building from the same subversion like i and Dag and Matthias are doing, then it is perfectly sane to do so. Normally you also try to avoid adding every repository which exists because then you get a lot of overlap.. of course you can use a tool like smart which is great for managing this. > 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. In my opinion, there will always be some standalone repositories: for example livna can't join Fedora Extras because it contains stuff which is not allowed in the USA. About the dist tags: o.el2, 0.rh7, 0.rh8, 0.rh9, 1.el3, 1.fc1, 1.fc2, 1.fc3 leads to a sane upgrade path. I never received one complaint of a user because i'm also using that... apparently it doesn't seem to be that confusing to people. There is no global registry for repo tags or dist tags but any person understands what 'fc3' means in a release tag. > 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. Trust is already granted to that packager because you've added his gpg key and his url to the apt/yum/smart configuration. > This is a dead end. Let's move forward. In my humble opinion, removing repo tags is moving backward. kind regards, Dries Verachtert