On Thursday 29 Jan 2015 01:03:38 Per Øyvind Karlsen wrote:
> Hi!
>
> For those who actively adds scriptlets to packages for systemd services,
> please stop doing this.
> This is no longer necessary as they're all handled by triggers, so you
> shouldn't need to have to carry around any scriptlets for services in your
> packages.
> By adding these scriptlets to your packages, you only add unecessary junk
> no longer being needed, while you also make *both* the file trigger and
> scriptlet for package to be run twice.
> Also by having the triggers that obsoletes the scriptlets, everything can
> be read in just one rune in a %triggerposttransin trigger, ie. like this:
>
> %triggerposttransin
> %triggerun units -- ^%{_unitdir}/.*\.(service|socket|target|path|timer)$
> echo $*| grep -q %{_unitdir}/[email protected] && exit 0
> ARG1=$1
> ARG2=$2
> shift
> shift
>
> units=${*#%_unitdir/}
> if [ $ARG2 -eq 0 ]; then
> /bin/systemctl --no-reload disable ${units} >/dev/null 2>&1 || :
> /bin/systemctl stop ${units} >/dev/null 2>&1 || :
> fi
>
> In this example the file trigger would only invoke systemctl twice with all
> tthe files matching passed as argument,
>
> By comparision if you were to use (only) the systemd macros in the
> scriptlets, then it'll invoke systemctl each time for every package
> installed, rather than all of file matches for transatction just being
> passed to systemctl just once per transaction.
>
> Also a benefit with systemd is that in contrast to old sys v initscript:
> # Provides: gpm
> # Should-Start: harddrake
> # Default-Start: 2 3 4 5
> where all of the settngs regarding when it should run or not being
> maintiained in the initscript, has now been moved out to separate config
> files under /lib/systemd/system-preset/,
> where the last file listed found is
> /lib/systemd/system-preset/99-default-disable.preset
> takes care of disabling any software that's not explicitly enabled.
> This helps freeing us from the what prevented adoption of file triggers for
> system v scripts earlier, namely that the scripts were run from scriptlets,
> for which whether the decission of individual packager usually would be
> decided whether enabling scriptlet or not as the common practice to
> disable/enable the services.
>
> As there was no standard way for the scriptlet to decide which services to
> enable or disable easily available to, running the trigger unconditionally
> for all services would really not have been a very good idea..
> With preset config on whether what services that should be enable or
> disabled is easily available and present under /lib/systemd-preset/, which
> a trigger
> would be able to properly deal with easily.
> You can create preset files easily, you can put ie. 'disable acpi.d* or
> 'enable acpid.* in either same or different files to be shipped by package.
> This will make it easy for the package mantainer to be in control of
> whether services distributed with their packages should be enabled or not,
> as /lib/systemd-preset/<filename>.preset.
> This in contrast to try maintaining the presets for *all* services that
> should be disabled or not in just file as done under ie.
> /lib/systemd/system-preset/90-default.preset.
> Deciding whether the services should be enabled or not should still lie in
> the hand of the package maintainer and configured with any individual
> configurations provided with the package.
>
> Maintaining everything in one big list in a critical package such as
> systemd is really silly, then you'll need to push a new release of the
> systemd each and every time any individual preset configuration that would
> need to be made to make the services of any other package on whether to
> disable it or not.
> Obviously we really don't want to have such a critcial package to be
> updated everytime whenever someone would want to change any preset
> configuration in various packages all around the distro in order to disable
> or not, then it should be obvious that this would not scale well. And make
> everyone having to make changes to systemd package and push out new release
> just for this, just in order to make changes to disable/enable any services
> in all the packages all around, would leave us with an annoying number of
> new package releases on frequent basis just because service preset
> configuration just being changes to configuration, something you most
> likely don't want everyone having to get too touch nor really want people
> without cøies with the packages makes other changes to it as well when
> pushing a new release just in order to enable/disable some services...
>
> The benefits of file triggers are well known, and something we've been
> actively trying to migrate our scriptlets to since Pixel's first file
> trigger implementation back in 2007, then later on enhanced by jbj & myself
> to provide proper control over file triggers at all stages of package
> installation just like scriplets provide "natively" using the existing
> trigger implementation for providing the same level of control as with
> scriptlets.
> These enhancements has made it possible to migrate more and more scriptlets
> to file triggers, making it easier to maintain packages with less garbage
> carried around spec files, while making them far easier and globally
> enabled for all packages in just one place, easy to find, easy to maintain.
>
> Well, unless anyone wants to dispute any of my statements and come up with
> some overwhelming arguments explaining why these scriptlets are
> systematically added to packages and the benefits, then please stop add
> scriptlets that's been deprecated by triggers, rather please remove them.
> This applies to scriptlets and triggers in general as well, if some
> scriptlet has been deprecated by a file trigger, then please rather start
> removing scriptlets deprecated by triggers.
>
> The benefits of file triggers also has nice benefits with the package that
> would be required to shoot of a trigger scriptlet would need to be present
> right away, namely avoiding dependency ordering issues with packages that
> carries the triggers executing requiring certain packages, dependency loops
> etc.
> This helps greatly, where all the files for packages already installed will
> also be passed as arguments to trigger script, making it easier to move the
> dependency that usually would be the package with whatever required by
> scriptlet, that requires to be installed before package is installed, while
> with triggers you can just as well have that package be installed at end of
> translacation, it'll only be executed affter the transaction finifshed.
>
>
> --
> Regards,
> Per Øyvind
Thank you for documenting this, I guess ultimately it should end up in the
developers section of the wiki as a permanent reference.
We need to find someone who has the time to do it. I guess we need a place to
queue such documents prior to insertion so at least they are not forgotten or
or worse lost.
Best
Colin
_______________________________________________
OM-Cooker mailing list
[email protected]
http://ml.openmandriva.org/listinfo.cgi/om-cooker-openmandriva.org
