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.
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
