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 -- packaging mailing list packaging@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/packaging
