Fedora Project launches Pre-Extras

[Dag Wieers]

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 at wieers.com,  http://dag.wieers.com/   --
[all I want is a warm bed and a kind word and unlimited power]