On Sun, 19 Dec 2004 03:08:30 +0100 (CET), Dag Wieers wrote: > 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. You continue to jump between "release tag", "dist tag" and "repo tag" as can be seen in above quote. > If you consider freshrpms a seperate repository for that matter, it would > not make a difference with or without repotag. Well, is it separate or is is not? > So you're looking at it with your authoritative glasses and ignoring the > reality of different repositories. Let us not wind up in off-topic talk. You cannot read my mind. You do not know whether I ignore anything. My scope is broader than you seem to think. It's just that I have different views with regard to a community project and collaboration and coordination between contributors from the community. I've learned some things with my own contributions at fedora.us, getting to know how other contributors think and what they hope for. Please be at least a little bit more conservative. The way you jump to conclusions or use your fedora.us related bitterness to drift away into personal attacks, just because I disagree, doesn't suit you. Fedora Extras is not me alone. Quite some discussions (and possibly also controversies) are still in front of us. > Besides this scheme allow us to have an upgrade path even when > the distribution changes name. Something you brought up yourself as an > example. I just mentioned the rh90 -> rhfc1 tag ugliness, a work-around which is still in use. The fedora.us jump from rh90 to 1 was criticised by a few people, too. 1.fc1 instead is no different. > > 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 ? We will find out whether there will be a policy for that or whether packagers will have the freedom to ensure it themselves. You don't see any significant problems in letting packagers maintain release bumps correctly, do you? Since Fedora Extras doesn't upgrade Fedora Core, you can't avoid branches in the development of an extra package forever. It will be natural that the EVR of a package for the latest FC release will be more recent than what will be available for older FC releases. This is bound to what build dependencies are available. Builds and rebuilds for the latest FC can increase the release version of a package monotonously. And how to increase the release version in updates for older distributions doesn't depend much on whether Fedora Extras will be released like Fedora Core or be a continuously updated release. As I see it, with full control over how the release field can be modified (except for restrictions imposed by RPM), the packagers need not worry about the pitfalls of a complex versioning policy, possibly with tags inserted by the buildsystem again. > > > 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'). Still no idea what you are referring to here, and losing interest.