On Sun, 19 Dec 2004, Michael Schwendt wrote: > On Sun, 19 Dec 2004 00:24:02 +0100 (CET), Dag Wieers wrote: > > > Exactly, there is no good reason and the repotag does not intervene. > > So repotags do not matter. > > They don't? > > http://heidelberg.freshrpms.net/rpm.html?id=594 > celestia-1.3.2-1.1.fc3.fr.i386.rpm > > http://dag.wieers.com/packages/celestia/ > celestia-1.3.2-1.1.fc3.rf.i386.rpm > > I started with freshrpms, then added your repository. What did I get? > An unnecessary upgrade of a 16 MiB package just because "rf > fr". > What did the upgrade add? Nothing. It was built from the same source > package, and the changelog is the same. > > In the extracted spec file in your repo, it reads "Release: 1", but > the %{release} querytag returns 1.1.fc3.rf actually. It's unfortunate, but it's irrelevant to the discussion. There's no good way to handle it, if freshrpms decided to use 2 as release tag (release + 1), my package would always be upgraded by freshrpms. This is a good argument to convince Matthias to use the .rf. tag too, as he's building from the same sources. But he's free to take another decision, just like anyone else that is rebuilding RPMforge packages. > > 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 > > Even more added complexity which must be tied deep into the buildsystem > to make sense? Is that uglyness really worth it? What you consider complexity, I consider the only reasonable way to allow what we need. You can't do this reasonably in RPM and the only alternative is making the release-tag different per distribution (release on fc1, release + 1 on fc2, release + 2 on fc3) which I considered but rejected because of the added confusion. I know Fedora does not consider or need it because of the limited scope. But again, don't generalize and call it ugly because your scope does not require it. > Out of interest, what would I do if celestia-1.3.2-1.1.fc1 needed a > fix specific to an API bug discovered in a library in FC1? The FC2 > rebuild would be celestia-1.3.2-1.1.fc2, and "fc2 > fc1". How would I > bump the version of the fc1 erratum to be newer than 1.1.fc1 but older > than 1.1.fc2? I said it had a pitfall because I knew you would focus on it. In this unique case we would upgrade both. I don't remember such a case, but in that case it's sub-optimal. Should we abandon a working solution because it does not cover all cases ? Especially when there's no alternative ? > > There are some pitfalls to this scheme, but [...] > > Please complete the missing details, i.e. all pitfalls presently > known. You pitch on benefits, but keep quiet about pitfalls and > deficiences. The one you mentioned is the only one I know. I did not mention it because I knew you would bring it up anyway (I can predict your rethoric now !) and because it does not matter in the discussion about the repotags. At least I mentioned there was a pitfall, I'm not deliberately hiding it. I'm sure you agree that disttags are necessary. Recently fedora.us decided to introduce them almost 2 years after we had the same discussion and it was rejected. Nice to see some improvements. -- dag wieers, dag@xxxxxxxxxx, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]