Mailinglist Archive: opensuse-factory (914 mails)

< Previous Next >
[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
< Previous Next >
Follow Ups