On Sun, 19 Dec 2004, 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? Exactly, there is no good reason and the repotag does not intervene. So repotags do not matter. And in the case you have an _exact_ match, the repotag can be used as an identifier by the user to pick one over the other. So thanks for agreeing with me over the issue. > What is the relationship between those two releases anyway? You can't know, they come from different sources. Maybe the sources worked together (like we do in rpmforge) and then it wouldn't matter. > 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. You see, we already have a working scheme for this. Very clever of you Michael. You're arguing in favor of us :) 0.el2 < 0.rh7 < 0.rh8 < 0.rh9 < 1.el3 < 1.fc1 < 1.fc2 < 1.fc3 < 2.el4 This scheme will even work when Fedora becomes Wagawaga. There are some pitfalls to this scheme, but nothing that can't be foreseen by a buildsystem or an experienced packager. > 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, You're now deliberately ignoring that packages are signed. Is this deliberate manipulating the discussion ? > and at the same time the .fdr tag, > which is used by more than one package vendor, is called a poor choice. It's a poor choice because it is too generic and essentially because it is used by different repositories. It doesn't offer some of the advantages if people decide/allow it to not be unique. > This is a dead end. Let's move forward. It is a dead end, you just hit the wall. Kind regards, -- dag wieers, dag@xxxxxxxxxx, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]