On Sun, 19 Dec 2004 01:49:49 +0100 (CET), Dag Wieers wrote: > > > 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. That would be something entirely different. We're discussing dist tags and repo tags. A pure release bump based upgrade between repositories which are advertised as compatible or belonging under the same umbrella, is even more unfortunate and unnecessary. > > > 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. There is not even a supported upgrade path between Red Hat Linux 9 and Red Hat Enterprise Linux 3, or Fedora Core 2 and Red Hat Enterprise Linux 4. By inserting the RHEL releases into the middle of the scheme, you make it even more complex and ugly. > 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. I'm not convinced that dist tags and repo tags are "required". > > 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 other examples, which demonstrate the drawback of added complexity. > 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 !) With hindsight you realise you might. But you're uncertain. > 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. Eh? What? Where? How? What improvements? "Recently"? What are you talking about? Is that a strange attempt at weird rhetoric? I see no change in the versioning scheme. It's the same old package naming scheme, which confuses contributors to hell and scares them, because it adds too much complexity and only some parts of it are good (vepoch).