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
Attachment:
pgpKWQF5n2MeR.pgp
Description: PGP signature
-- packaging mailing list packaging@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/packaging
