On Thu, 01 Mar 2007 04:35:59 -0500, David Zeuthen wrote:
Can we please stop doing such things just because some people
don't like
the Epoch being bumped? No-one have ever given good technical reasons
for this, only
- "it's ugly"; or
- "some software is broken and don't know about Epoch"; or
- "it's Rawhide, nobody should expect Rawhide to work"
To me it just seems, how shall I put it, non-constructive to put users
through a manual downgrade ordeal just to preserve one number that, for
the record, is meaningless already.
So, consider this a request for our various packaging committees to take
action and make our packaging guidelines reflect that we just don't do
things like this. Of course, if there exist technical reasons for not
bumping the Epoch, I don't pretend to be a packaging gure by any means,
that I'm not aware of I apologize for this noise.
A technical reason for avoiding Epochs is that at the RPM level, the
software version of a package is not independent from the package
version. When adding an Epoch to a package, the Epoch becomes a necessary
part of all forms of RPM version comparison. This introduces weaknesses in
non-automatic versioned dependencies and requires packagers to specify the
exact %{epoch} in all such dependencies to keep them strict.
Example:
Name: bar
Requires: foo >= 1.0
would be satisfied by
Name: foo
Version: 0.5
Epoch: 1
because due to the Epoch, the smaller %version wins RPM version comparison.
A solution to the problem would be to either avoid explicit dependencies
on versioned _package names_ or introduce more virtual capabilities of the
form
Provides: foo(api) = 1.0
Provides: foo(abi) = 1.0
which would remain free of Epochs.