On Sat, 01 Nov 2003 12:21:59 +0100, Nils Philippsen wrote:
On Fri, 2003-10-31 at 18:00, Michael Schwendt wrote:
> On Fri, 31 Oct 2003 04:31:09 -1000, Warren Togami wrote:
> > > Are there cases where rpm would consider imap-2000a as older than
> > > imap-2000?
> > >
> > > jbj?
> > >
> > Err... you are completely right about it not being necessary in the
> > post-release case. I am not sure why our fedora.us policy retained that
> > even though it was unnecessary for all these months. The way I
> > understand the older version of rpm broken rpmvercmp behavior, this
> > wouldn't be a problem with those versions too.
> * To be able to go back from 2.1.7a to a patched 2.1.7 in case the
> 2.1.7a post-release "fix" turns out to cause side-effects.
Hmm I'm not sure if I buy that -- extrapolating form that, one should
also be able to go back from 2.1.8 to 2.1.7 in case the new version
turns out to cause side-effects (without any "--oldpackages" stuff or
that point is moot).
That would be something different, since I assume 2.1.8 comes quite
some time after 2.1.7. On the contrary, 2.1.7a would be sort of a
quick brown paperbag fix attempt which would be released shortly after
2.1.7, often just a few hours later or on the same day. Including such
an upstream fix prior to publishing a package is tempting, and
sometimes it turns out right after release that the fix breaks other
parts of the software in an unexpected way and the real fix takes more
I'd a fan of serial numbers, but not when they're hidden. I would
even like a scheme like
I think the version should always be the upstream version where
are not incompatible with RPM version comparisons and real version
numbers (and not CVS dates or the like because they may be substituted
with real version numbers which are likley less RPM wise) and (optional)
characters represent newer patch levels (and not prereleases). If that
version number contains dashes, replacing them with underscores might be
Not "might be necessary", it is a strict requirement by RPM.
> * Consistency above all.
Care to explain that one? Of course the idea I have about versioning
seems most consistent to me but I'm sure you can shed some light on why
version numbers differing from upstream are more consistent ;-).
Since you understand the need for a pre-release version/release
modification guideline, you do understand this guideline very well,
too, and hence it doesn't need much of an explanation IMO.
> * The road of least surprise (with regard to upstream
That's what I want.
> * To help avoid that users think foo-1.0a would be an unstable alpha
> version, when in fact it is a post-release patch-level.
I do not think that is the purpose of an RPM version tag. It exists so
the user knows that this is the upstream version number-- how else would
a user be able to submit bug reports upstream if he cannot supply the
real version number/string/whatever.
The user should find the software version number in the "About" or
"Help" sections, in the manual and should never rely on package
versioning. E.g. KDE 3.1.4-6 is not an upstream version, GCC 2.96
wasn't either. Now don't tell me all users know what the release
version is. Why should it be allowed (or make sense) to modify
1.0rc3-2 to 1.0-2.rc3, but not 1.0pl1-2 to 1.0-2.pl1?
If users interpret version strings
like "1.0a" as an alpha version when they're not -- well, that's tough
luck but nothing that should be worked around by some RPM version
It's not a primary goal, but it helps. It should not be user's
responsibility to know that Mozilla 1.5a is older than 1.5, but Foo
1.5a is a bug-fix release for Foo 1.5. The package release version
should make that obvious. Else user keeps using the unstable Mozilla
1.5a as long as rpmseek.com
doesn't list a newer version.
I don't like the dependency on upstream versioning at all, cases such
as 1.01 > 1.0.2, 0.6 > 0.50, 0.010 > 0.1, 1.2 < 1.02, 1.0a < 1.0 or
1.0a > 1.0, ... not all can be dealt with without modifying these