[Fedora-packaging] Systemd scriptlet comments

[Toshio Kuratomi]

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
> >>
> >> 1) 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.

> >> 3) 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/packaging/attachments/20110624/3416017a/attachment.bin