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
_______________________________________________
OM-Cooker mailing list
[email protected]
http://ml.openmandriva.org/listinfo.cgi/om-cooker-openmandriva.org
