ANNOUNCE: bittorrent downgrade

[Michael Schwendt]

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.