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