rpm: avoiding evil epochs and split versions

[Axel Thimm]

On Fri, Oct 31, 2003 at 05:53:58AM -0500, Mike A. Harris wrote:
>  My personal preference would be to just let rpm assume that as it
>  should work.  I've never gotten bug reports of it not working
>  anyway.  Moving things from the version to the release field
>  unnecessarily just complicates packaging when there's no real
>  benefit IMHO.  For the pre-release cases above it makes sense as
>  it's being done in order to override rpm's default behaviour,
>  which would be to treat what is a final release as older than a
>  prerelease.
>  
>  I believe treating both pre-release and post-release in the same
>  manner just for consistency with both types of lettered versioned
>  packages is just cosmetic consistency, but doesn't provide any
>  functional or technical benefit.  In other words, sticking with
>  the upstream version in the version field is IMHO best unless
>  there is a technical benefit of doing so, such as avoiding having
>  to later use Epoch to override a prerelease build. 
I agree, and rpm (and deb for this matter) should be redesigned long
term to have different semantics of a upstream version used for
rpm/deb ordering and one used for the package name. So
foo-1.2.3beta17.8 could be packaged as foo-1.2.3beta17.8-1.rh9, but be
compared as say 1.2.2.99.17.8.

This could be done at the cost of introducing a new tag like
versionsort that defaults to %{version}. When present it would be used
for ordering and interpackage dependencies (Requires, Conflicts,
Obsoletes etc.).

It would make epochs unnecessary and it would be a local (in time)
change of a package (contrasted to epoch's global and eternal presence
...).

This was proposed on the rpm-list ages ago, but died a silent death,
maybe it could be resurrected here?

>  Are there cases where rpm would consider imap-2000a as older than 
>  imap-2000? 
No, not since rpm >= 4.0.3 (#21392).
-- 
Axel.Thimm(a)physik.fu-berlin.de