On Sun, 19 Dec 2004, Michael Schwendt wrote: > On Sun, 19 Dec 2004 01:49:49 +0100 (CET), Dag Wieers wrote: > > > 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. Well, it is not a good argument for getting rid of the repotag, it's a good argument to have freshrpms use the same repotag Dries and I have settled to. But again, that's up to Matthias. If you consider freshrpms a seperate repository for that matter, it would not make a difference with or without repotag. So you're looking at it with your authoritative glasses and ignoring the reality of different repositories. > > > > 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. There isn't a supported upgrade path, still people are doing it. Even in production and inside corporations. Don't be limiting yourself to what is supported. Besides this scheme allow us to have an upgrade path even when the distribution changes name. Something you brought up yourself as an example. > > 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". Well, that's obvious from your replies. How is Fedora Extras going to make sure packages get updated between releases ? > > > 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. I haven't seen any that make sense in the real world. But you keep mentioning them :) > > 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. Bring me one, don't bring fear, uncertainty and doubt. It does not suit you very well. > > 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? Hehe, sorry, only the Freshrpms packages in pre-FC3 have disttags, I'm sure this will be fixed in time because, good god, it also contains repotags (or as Seth calls it 'branding'). But at least Red Hat is adding them recently for a few packages, which is good progress. -- dag wieers, dag@xxxxxxxxxx, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]