Triggers in dpkg/APT? [LWN.net]

Triggers in dpkg/APT?

Posted Jul 30, 2004 1:15 UTC (Fri) by AnswerGuy (subscriber, #1256)
In reply to: Strawman problems or poorly done homework? by vmole
Parent article: OLS: An introduction to Conary

One think I'm curious about. Is there support in the Debian packaging system for triggers (like RPM has)?

Triggers don't seem to be widely used (packager ignorance?) but they seem like a neat idea. With some carefully designed standards among packages
they could make your package management system almost "object-oriented."

(Consider: you install a mail user agent (MUA) which registers a trigger on the virtual package MTA. When any MTA is installed, the trigger runs a script which invokes the MTA's own MUA registration script. Now all MUAs can have some setting adjusted when an MTA is replaced. All of the MUAs "know" whether the system is using mbox, maildir, or MMDF system mailboxes --- for example).

(Sorry if the example is silly --- better examples might relate to registration of menu items and icons in window managers or something).

JimD

(Log in to post comments)

Triggers in dpkg/APT?

Posted Jul 30, 2004 13:08 UTC (Fri) by frodonl (subscriber, #16826) [Link]

While I don't know about any triggers functionality in the Debian packaging system - I never needed them, so I never really searched for it, Debian does define a standard way to create menu items, called the Debian Menu System.

It works by postinstall and postrm scripts calling one central command (update-menus) that will call the menu-update scripts for the various packages that use "menu managers".

Grtz,

Frodo

Triggers in dpkg/APT?

Posted Aug 3, 2004 16:43 UTC (Tue) by angdraug (subscriber, #7487) [Link]

Assessment of triggers is the one thing in the Conary whitepaper that I tend to agree with. Triggers require that too many packages know too much about each other: this creates more complexity and points of breakage than it's worth. Think of it as dependency hell on drugs.