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