2015-01-29 18:18 GMT+01:00 Colin Close <[email protected]>: > On Thursday 29 Jan 2015 10:00:14 Per Øyvind Karlsen wrote: > > 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. :) > > The trouble with this approach is that people who can deal with wikis but > who can't deal with rpm stuff can't contribute. > A simple document format that can be expanded by the wiki writer is what > is needed from > any developer implementing new features. > > A simple approach such as this:- > > Purpose and Description: > Usage: > An example. > > Would serve the purpose. > > Undocumented features don't get used. In my short experience of rpm I have > seen countless fragments > beginning with % which I have absolutely no idea what they do. > Now you may say that I should find out :) well one can but the amount of > time spent doing so can be prohibitive. > > > > > 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 > > Forgive me for saying this proyvind but any professional software engineer > would count documentation as part of his/her job. > Would you write code without comments or give somebody a new piece of > equipment that you want them to use but don't tell them how. > Of course not. The thing is that nobody else understands it better than > the person who created it. > We all hate doing the less fun bits but they have to be done > You seem to forget the obvious fact that I'm no longer professionally writing this software, whereas this project is a community effort.
There's tons of examples spread around in spec files, many people has succesfully figured them out and adopted them, most of features are fairly intuitive, and for the trigger implementation it's been documented for several years under /usr/share/doc/rpm/triggers (trigger implementation in rpm is nothing new, the only new thing about it is support for triggering on paths and also triggers for pre- & posttrans.) While I'm not trying to boast about the large amount of software I write for this distribution compared to pretty much anyone else, it does take up a lot of time, time others could contribute their help as a community efforts on helping writing documentation for the work I produce. And as I already said, the examples you'll find in spec files throughout the distro are fairly self-explanatory, whileas I have no problem answering questions for anyone who would do the kind effort of helping out documenting packaging policies, functionality, new features and what not, along the same lines as for the most content that the wiki consists of.. If I were to document all policies, new functionality, and what not on all the software I'm developing in the context of this distro, that would be an incredibly unfair share of workload.. By comparison, I'm *quite* sure Panu isn't actively documenting everything relating to rpm on the fedora wiki... -- Regards. Per Øyvind
_______________________________________________ OM-Cooker mailing list [email protected] http://ml.openmandriva.org/listinfo.cgi/om-cooker-openmandriva.org
