2015-01-29 9:27 GMT+01:00 Colin Close <[email protected]>: > 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. > Yes, most certainly, I'll try get myself an account for edititing on the wiki myself, but since I have a lot on my table and is the only guy who does development on ~new rpm features and several other piecese of crucial software in the distro, a lot of new stuff has yet to be document and the adoption of has been lingering quite a lot as a result. Ie. the last %triggerposttran* triggers were added like three years ago, and with this new trigger type, the triggers should be pretty much feature complete now, with the legacy /var/liib/rpm/filetriggers being deprecated by as all of it's functionality and previous benefits over the native triggers has been dealt with for the native triggers. I will soon enable rpmlint checks to disallow legacy triggers in order to force people to migrate them to native ones, while also add checks to prevent usage of various scriptlets that's no longer needed due to triggers deprecating them.
There's as said several other new stuff that needs to be documented, so I hope people would be willing to help me out doing so on the wiki. For many new features, there exists examples in various packages throughout the distro that implements usage of, which should be mostly self-explanatory enough for people to understand their usage and thus be able to properly document it on the wiki. For anyone who has any questions about any new features, their usage, benefits etc., either for the sake of documenting it, or just simply how to use in packaging, I'll be happy and more than willing to answer any questions you might have regarding. :) So yeah, I'm having difficulties with being able to document all new stuff, especially due to inability to scale and mostly being alone doing the development alone, so help on this would be *greatly* appreciated. :) -- Regards, Per Øyvind
_______________________________________________ OM-Cooker mailing list [email protected] http://ml.openmandriva.org/listinfo.cgi/om-cooker-openmandriva.org
