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 at physik.fu-berlin.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20031031/57889ca6/attachment.sig>