[opensuse-factory] First usage of file triggers is on the way to Tumbleweed
Hi everybody, As many of you are certainly aware, RPM 4.13.0 brought, amongst other things, the ability to use file triggers (i.e. run a script whenever a package installs/removes a file to a specific directory) There are various points where I could make out where this makes a lot of sense - and which have been a constant point for bug reports because packagers forgot to add the respective post/postun scriptlets (who can blame them...) The 4 things I made out so far are: * glib schemas, installed to /usr/share/glib-2.0/schemas (this requires calling glib-schema-compile) * icons installed to /usr/share/icons/FOO: the icon cache needs to be updated in order for the various DE to reliably show them * /usr/share/mime - the mime database needs to be updated * .desktop files added to /usr/share/applications: we have macros in place to update the desktop database cache For all 4 those cases, there were macros (e.g. %desktop_databasE_post/postun for the .desktop files) In GNOME:Next (preparation for GNOME 3.26 - ETA September 2017) all 4 of those usecases have already been replaced (and so far that works reliable) The FIRST of those triggers is now on its way to openSUSE:Factory - the one handling /usr/share/applications/*.desktop files, as part of https://build.opensuse.org/request/show/507346 The existing macros, %desktop_database_post and %desktop_database_postun have been redefined to %nil in this submission => What does that mean for you / actions do you have to take In short: nothing and none. Your existing packages will continue to work as they did and no change is needed directly. If your packages are only targetting Leap15/SLE15/TW, you could even go forth and remove the respective %desktop_database_post/postun calls from your .spec files; they won't be doing much anyway. If you target your packages for older releases, you very likely don't want to change anything anyway - and rely on the fact that the RPM macro is simply not going to do anything anymore. What you might want to do though is stay alert on bug reports that might indicate that the desktop database is not updated timely, so that we can investigate why this could be and counter steer on it. Cheers, Dominique
Am Fri, 30 Jun 2017 16:17:43 +0200 schrieb Dominique Leuenberger / DimStar <dimstar@opensuse.org>:
As many of you are certainly aware, RPM 4.13.0 brought, amongst other things, the ability to use file triggers (i.e. run a script whenever a package installs/removes a file to a specific directory)
"a script" as in a single, global script per "file"? Or rather "at least one script" per "file"? In case of the latter: what defines the ordering? Would a pkg B be able to override the system provided pkg A? Olaf
On Fri, 2017-06-30 at 20:11 +0200, Olaf Hering wrote:
Am Fri, 30 Jun 2017 16:17:43 +0200 schrieb Dominique Leuenberger / DimStar <dimstar@opensuse.org>:
As many of you are certainly aware, RPM 4.13.0 brought, amongst other things, the ability to use file triggers (i.e. run a script whenever a package installs/removes a file to a specific directory)
"a script" as in a single, global script per "file"? Or rather "at least one script" per "file"? In case of the latter: what defines the ordering? Would a pkg B be able to override the system provided pkg A?
'a script' is an rpm scriptlet - defined in the .spec file (as were %post scripts) The file trigger is defined 'per location to be monitored' The script is started 'once per package that installed files' (in case of filetriggerpost) - and gets the file list as input (so it can do something out of it) The rpm scriptlet can have a weight - which could define the order in case more than one file trigger hits (so far I did not see a need for this and the 4 triggers implemented are all the same weight) For the interested ones, the rpm documentation can be a worthy read: http://rpm.org/user_doc/file_triggers.html Cheers, Dominique
participants (2)
-
Dominique Leuenberger / DimStar -
Olaf Hering