This came up on IRC the other day, and as I'm finishing up the conversion of my packages I realize that I don't know the proper answer.
Packages converting to systemd are mandated by https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd to include a trigger:
%triggerun -- zoneminder < 1.25.0-4
Assume that F16 is at 1.25.0-3.fc16 and F17 is at 1.25.0-4.fc17
Now, there's a caveat that any update to F16 keep a ver-rel less than 1.25.0-4. Which is fine if you just need to tweak the package, since you can use 1.25.0-3.fc16.1.
I don't, however, recall any discussion about what the packager is supposed to do if 1.25.1 comes out (and for fun, assume it fixes a huge security hole and is absolutely essential). What does F16 get? The options seem to me to be:
* Just update F16 to 1.25.1-1.fc16 and deal with the fact that the trigger doesn't get run.
* Update to 1.25.1 but lie and call it 1.25.0 in the rpm version.
* Freeze the F16 version at 1.25.0 and ignore bug reports.
The only thing that makes any sense to me (perhaps because this whole trigger and systemd-sysv-convert thing seems entirely pointless) is to just do the first option. Is there anything else to be done? I suppose it should be theoretically possible to do the second option and encode the real package version in the release somehow (1.25.0-3.fc16.1.1.25.1.fc16 or something crazy like that) but that seems even less palatable than just dropping the trigger and requiring admins to do systemctl enable zoneminder.service. Which, not coincidentally, is something they pretty much have to do anyway.
- J<
Jason L Tibbitts III wrote:
This came up on IRC the other day, and as I'm finishing up the conversion of my packages I realize that I don't know the proper answer.
Packages converting to systemd are mandated by https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd to include a trigger:
%triggerun -- zoneminder < 1.25.0-4
Assume that F16 is at 1.25.0-3.fc16 and F17 is at 1.25.0-4.fc17
Now, there's a caveat that any update to F16 keep a ver-rel less than 1.25.0-4. Which is fine if you just need to tweak the package, since you can use 1.25.0-3.fc16.1.
I don't, however, recall any discussion about what the packager is supposed to do if 1.25.1 comes out (and for fun, assume it fixes a huge security hole and is absolutely essential). What does F16 get? The options seem to me to be:
- Just update F16 to 1.25.1-1.fc16 and deal with the fact that the
trigger doesn't get run.
Update to 1.25.1 but lie and call it 1.25.0 in the rpm version.
Freeze the F16 version at 1.25.0 and ignore bug reports.
The only thing that makes any sense to me (perhaps because this whole trigger and systemd-sysv-convert thing seems entirely pointless) is to just do the first option. Is there anything else to be done? I suppose it should be theoretically possible to do the second option and encode the real package version in the release somehow (1.25.0-3.fc16.1.1.25.1.fc16 or something crazy like that) but that seems even less palatable than just dropping the trigger and requiring admins to do systemctl enable zoneminder.service. Which, not coincidentally, is something they pretty much have to do anyway.
If you don't want to freeze F16 version, then you have to introduce an Epoch into the F17 package. Best to avoid Epoch whenever possible (since you introduce it forever), but in your case you can't really avoid it.
Jamie
"JN" == Jamie Nguyen jamie@tomoyolinux.co.uk writes:
JN> If you don't want to freeze F16 version, then you have to introduce JN> an Epoch into the F17 package. Best to avoid Epoch whenever possible JN> (since you introduce it forever), but in your case you can't really JN> avoid it.
I'm struggling to understand how an epoch will help.
Obviously when updating the F16 version you'd update the F17 version as well; there is no problem with F17>F16 version ordering. But the fundamental question is what happens to the version for the %triggerun? You can't change it, can you? But if you don't change it then now upgrades from the updated F16 package to the updated F17 package don't get systemd-sysv-convert run.
- J<
Jason L Tibbitts III wrote:
I'm struggling to understand how an epoch will help.
Obviously when updating the F16 version you'd update the F17 version as well; there is no problem with F17>F16 version ordering. But the fundamental question is what happens to the version for the %triggerun? You can't change it, can you? But if you don't change it then now upgrades from the updated F16 package to the updated F17 package don't get systemd-sysv-convert run.
%triggerun version should stay the same, and should be the version that systemd was first introduced.
If you don't use an Epoch, bumping the F16 version will cause the %triggerun script not to run.
An Epoch allows you to bump the version of the F16 package freely, without worrying about breaking the upgrade path. It doesn't matter what version the F16 package reaches, upgrading to F17 will still always result in %triggerun being run.
"JN" == Jamie Nguyen jamie@tomoyolinux.co.uk writes:
JN> %triggerun version should stay the same, and should be the version JN> that systemd was first introduced. JN> If you don't use an Epoch, bumping the F16 version will cause the JN> triggerun script not to run.
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.
- J<
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@lists.fedoraproject.org
-
Jamie Nguyen -
Jason L Tibbitts III