dpkg in experimental supports triggers now, and in many cases trigger support can be added to packages without creating a hard dependency on a new version of dpkg.
Things I want to see use triggers, in approximate priority order:
- scrollkeeper
This is a huge speed pig, and d-i has hacks to disable it and
run it at the end that I would love to be able to remove.
dpkg's triggers.txt has a plan for triggerizing it
- tetex stuff
Also very slow. Maintainers already plan to use triggers.
- update-menus
Run by zillions of postinsts and postrms, many of these can be
gotten rid of entirely by using triggers, which is a big
complexity win.
I have written a patch for initial trigger support in menu. (#473467)
- ldconfig
Seems to be some uncertainty about where it's possible to
triggerize this safely and reliably.
- update-mime
- update-mime-database
We could probably speed up desktop installs by about 1 minute by
triggerizing these.
- update-icon-caches
- update-desktop-database
These are not very slow, nor used by a great many packages,
but triggerizing them would allow getting rid of dh_icons and
dh_desktop eventually, which I would appreciate.
- install-info
Currnently it has to be told which info file has changed, but
that could easily be removed. Triggerizing this would simplify
some maintainer scripts. (Only ones that don't need to pass
install-info any options.)
--
see shy jo
signature.asc
Description: Digital signature
