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
Attachment:
signature.asc
Description: Digital signature