Jason L Tibbitts III wrote:
I guess I'm just being dense, but the only thing Epoch can do is
make
the package even newer and I don't see how that helps to keep the F16
version older than the version in the trigger definition. Or are you
suggesting adding the epoch up front in F17, using it in the trigger
definition and keeping the F16 version without the epoch so that no
matter what it's always older? I guess that would work, but I can't
imagine that this is worth introducing an epoch over.
In any case, if that's really what we (FPC) would recommend, we'd need
to write it down in the guidelines.
An example is for nginx, which I recently migrated to systemd for F17
(in updates-testing):
nginx 1.0.12-1.fc16
nginx 1:1.0.12-2.fc17
In F17 package there is: %triggerun -- nginx < 1:1.0.12-2
The %triggerun version is now fixed and must remain in the F17
package. Without the Epoch, it's not possible to bump the version of
the F16 package without breaking the %triggerun scriplet.
It's the only way I could see that allowed me to bump the F16 version
when the next upstream release is made. When tracking the same
upstream version in both F16 and F17, Epoch is the nicest (ahem) way
to preserve the upgrade path, since I don't think obscuring the real
version or freezing the package completely are usable alternatives.
Jamie