FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Packaging

 
 
LinkBack Thread Tools
 
Old 02-25-2012, 05:41 PM
"Jason L Tibbitts III"
 
Default Systemd conversion trigger question

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<
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 02-25-2012, 06:41 PM
Jamie Nguyen
 
Default Systemd conversion trigger question

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
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 02-25-2012, 08:14 PM
"Jason L Tibbitts III"
 
Default Systemd conversion trigger question

>>>>> "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<
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 02-25-2012, 08:39 PM
Jamie Nguyen
 
Default Systemd conversion trigger question

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.
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 02-25-2012, 11:35 PM
"Jason L Tibbitts III"
 
Default Systemd conversion trigger question

>>>>> "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<
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 02-25-2012, 11:58 PM
Jamie Nguyen
 
Default Systemd conversion trigger question

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

Thread Tools




All times are GMT. The time now is 06:35 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org