On Fri, Jun 24, 2011 at 01:37:02PM +0300, Ville Skyttä wrote:
On 06/22/2011 07:24 PM, Toshio Kuratomi wrote:
On Fri, Jun 03, 2011 at 11:02:34PM +0300, Ville Skyttä wrote:
Some comments on systemd scriptlets at http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd
- I don't think the versioned trigger logic will work too well at all
in the (not that rare) cases where the previous distro had sysv scripts and one does a version bump in the previous distro - the trigger in the next one will no longer run on distro upgrades because of the versioning. Wouldn't it work better to just drop the version from the trigger altogether, and instead check if the old init script exists? For example:
%triggerun -- httpd [ -e %{_initddir}/httpd ] || exit 0 # rest of the migration stuff goes here
We discussed this when we came up with the guidelines. IIRC, we finally decided this wasn't workable because we don't prevent people from packaging systemVinit scripts (either in subpackages or in a wholly separate package.
I agree with your points about fragility, though. If you can think of a way that handles both I'd be happy to hear it.
Just a couple of unfiltered thoughts, reader beware; haven't spent much thought or time on these yet:
a) If people do package/have sysv scripts alongside systemd ones, is it desirable to make the systemd migration happen on upgrades in the first place?
I'm not sure.... In earlier days when we had other init systems coexisting alongside of sysvinit scripts, we were able to boot with init=/sbin/other_init provided that we had "init scripts" for the services we cared about for the other init system.
If that's still the case we're shooting for, then I think we do want to have migration happen on upgrade.
b) Maybe checking for existence of the systemd unit file in addition to the sysv script in the above recipe could have some positive properties.
I don't think this works.
Lets say you have:
foo-1.0-1 (sysv) foo-1.0-2 (systemd) sysvinit-basescripts-1.0 (which contains sysv init scripts for foo).
We want to perform migration when foo-1.0-2 (or later) replaces foo-1.0-1 but not if the init script is provided by sysvinit-basescripts. This doesn't seem to be predictable based on presence or absence of systemv init scripts and systemd unit files. It's ambiguous whether the presence of a sysvinit script came from the foo-1.0-1 package and therefore means that we're upgrading or if it came from the sysvinit-basescripts package and therefore means we're trying to configure the system to boot with a sysv init system.
For the packages I migrate to systemd, I don't plan to keep any sysv init scripts around, and the version bump problem would lurk out there ready to bite if I used the currently documented scriptlets. So I'm going to use the sysv script existence check way instead.
Unfortunately, this isn't enough as someone providing init scripts for your service in a separate package can ruin detection based on presence or absence of the init script.
- More or less cosmetic: why hardwire absolute paths everywhere? The
vast majority of other scriptlet snippets don't do that.
I've replaced /usr/bin with %{_bindir} now.
That removes the "hardwire" part for a few cases, but doesn't address the "absolute" part.
Are there other paths that we could change?
I'd personally remove all absolute paths to commands in standard PATH from the scripts altogether where possible, macroized or not. The Gconf, GSettings, gdk-pixbuf, GTK+ modules, GIO modules, Scrollkeeper, desktop-database, mimeinfo, and Icon Cache scriptlets and macros are already written without unnecessary absolute paths. The only ones that do contain apparently unnecessary absolute paths are Systemd and Texinfo. Why?
Ah I see -- I tend to agree but I don't know what the other packaging committee members think so I've added it as a ticket for the next meeting:
https://fedorahosted.org/fpc/ticket/96
-Toshio