On Mon, Oct 06, 2003 at 03:50:49PM -0400, Mike A. Harris wrote:
On Mon, 6 Oct 2003, Axel Thimm wrote:
> The fact is that there still is no versioning scheme one can rely
> upon. The scheme we discussed with fedora.us in March/April is now
> broken.
>
> The main issue is, that RH need to come up with a consistent
> scheme (not only for fedora but also including fedora legacy), or
> bless an existing one.
>
> Currently there is no schem that will work:
> o either the upgrade paths are broken, e.g. rh9 -> fc1/fdr1
> o or rpm bugs are triggered, e.g. rhXX -> numbers
> o Red Hat policy is violated, e.g. rh9 -> rh10
Reading the thread, it is aparent to me that many people who read it
and responded, did not completely listen to the problem which you
are describing. Numerous people completely misunderstood what you
are trying to say, or purposefully chose to not read everything and
attempt to understand it. I read your emails fairly carefully
however and believe I understand you correctly.
Without renaming or reversioning the distribution (which is just
straight plain and simple not going to happen period for any reason
short of an Act of God(TM)), there is another extremely simple
solution. Simply add an additional digit in front of the normal
modifier you use to indicate your special packages.
For example:
RHL 8.0: foo-1.2.3-3.rh80
RHL 9 : foo-1.2.3-3.rh90
FC 1 : foo-1.2.3-3.1fc1 or foo-1.2.3-3.0fc1 or
foo-1.2.3-3.1.fc1
This breaks with all rpm versions shipped until the beginning of this
year (including RH8.0). On rpm-list we rediscussed in January the rpm
non-symmetric bug (or letter-number toggling bug) that invalidated
ordering of segments of different types.
While there do exist backported rpm versions with this bug fixed on
rpm.org, they have not been approved to enter RH errata, yet, and a
Legacy project needs to take into account non-updated setups.
Therefore this solution, as well as dropping the letters completely
(which would have worked with the same semantics) is flawed for a
Legacy project (See also the renamed "Fedora and Fedora Legacy package
versioning schemes", where this is discussed in more detail.)
Thanks for the suggestion, though, and for taking your time to go
through it. As you noticed, only few do.
Currently I think the best way would be for RH to allow to tag the old
releases with tags like 0.7.3, 0.8.0, 0.9 to make the versioning
ordered again.
Using this scheme, all of the packages with fc1 in their names
are considered newer by RPM than the RHL 9 or 8.0 packages above
them. No Epoch specifier is needed, no reason that the
distribution naming/versioning scheme we've chosen to go with
will break your packages. It may require some getting used to,
but the problem is trivially solveable by you for your package
repositories, and by others with their package repositories.
The reason this works, is because when rpm goes to compare 2
packages to see which is newer, it compares based on name + epoch
+ version + release. The version and release fields are compared
like this (this is fairly oversimplified):
It breaks the release field into multiple parts on field
boundaries. A field boundary occurs when the next character
transitions from alpha to numeric or numeric to alpha, or by an
optional "." or "_" delimiter character[1]. Numerals are
considered higher than alphabetic characters in a given field
number.
So taking the 3 examples above and splitting them up into fields
and comparing them, we have:
Release Field1 Field2 Field3 Field4
3.rh80 3 rh 80 N/A
3.rh90 3 rh 90 N/A
3.0fc1 3 0 fc 1
3.1fc1 3 1 fc 1
3.1.fc1 3 1 fc 1
Field 1 matches for all of them so comparison proceeds to field
2, in which case 1 is newer than 0, which is newer than "rh", so
the fc1 packages are all newer than both the rh80 and rh90
packages.
Problem solved.
Hope this helps.
TTYL
[1] There may be other delimiters I'm forgetting also, but I'm
not trying to be 100% complete here to what the rpm source code
handles, just trying to give a fairly terse example. In general,
it is best to stick to using only numeric and alphabetic
characters and ".". When in doubt, consult RPM documentation,
and source code for the complete gory details if one requires
more advanced knowledge than my terse description provides.
--
Axel.Thimm(a)physik.fu-berlin.de