On Sun, 19 Dec 2004 05:04:51 +0100 (CET), Dag Wieers wrote: > > > 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? > > It's build from the same source, which is an improvement even though we're > not using the same repotag. It's not seperate regarding compatibility (you > can safely mix), but it acts seperately because of the repotag in your > example. Again a consequence of the freedom of the packager, but an > improvement from build and compatibility perspective. An improvement, I agree. But still half-hearted with regard to common components. > [...] But Fedora Extras will most likely not need repotags, while > we're discussing the usefulness of 3rd party repositories. We are not discussing the usefulness of 3rd party repositories. 3rd party repositories even are anchored in the Fedora Project objectives. We're discussing pollution and abuse of release number fields and how to avoid that. > I don't mind if Fedora Extras does not use them, but I do mind when Seth > or you are saying it 'pollutes', is branding, is a hack, does not have a > purpose or anything else that has been misleading to the general public. Well, I agree with Seth, and I haven't discussed repo tags with him before. > > > 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. > > Thanks. Each scheme will have advantages and disadvantages. None of my > users have complained so far and we've explained why it is there. So it's > strange that outsiders have a problem with it, while everyone using it > don't care :) Users don't complain about implementation details. They want the whole thing to "just work". They don't care what magic is used to make one package be seen as newer than another. You could even use the internal Epoch as a serial number (like old "Serial:" tag is still used by some people). Users complain as soon as the whole thing breaks or results in unexpected behaviour (such as compatible repositories upgrading eachother unnecessarily). > The reason Matthias is not using the 'rf' tag is because I'm not forcing > anyone. It should not be necessary to force or urge anyone. To be successful with collaboration and joint efforts sometimes means that participating parties should be willing to compromise. > The most important fact was having the building merged, the > repotag is in no way as important as that change alone. As I pointed out, that was a first step. A small piece of the cake. > > > > > 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. > > http://fedoraproject.org/pre-extras/3/i386/js-1.5-0.rc6a.1.fc2.fr.i386.rpm > http://fedoraproject.org/pre-extras/3/i386/xplanet-1.0.1-0.fdr.5.2.i386.rpm That's an example of the old fedora.us versioning scheme, which managed to sneak into the unofficial pre-Extras builds for reasons I can only presume. In CVS, it's xplanet-1.0.1-5 since Dec 11th. I guess the release bump came a bit too late for some of Seth's rebuilds. And Matthias has not edited all his packages in CVS yet, so some of them still have an old reason. You may need to spend a few more words on explaining what you refer to in the beginning of the quote above.