Hi! On Tue, 2014-12-02 at 06:46:33 +0800, Thomas Goirand wrote: > On 12/01/2014 04:26 PM, Thorsten Glaser wrote: > > No, triggers unfortunately are not that simple: if you install/upgrade > > openstack-dashboard together with some of the packages it wants a > > trigger on, $1="triggered" will sometimes not happen, only "configure".
> > The thing to call when triggered is the upgrade_mediawikis shell > > function, it’s called from the “triggered” case, but also from > > the regular “configure” case. This is suboptimal, but apparently > > needed. Well if you install the interested package and nothing triggers, and you need to run the action that would normally be done when triggered then sure, you'd also perform that action on configure. > So if I understand well (by reading your example package), the only > thing I have to do (for horizon) is: > > 1/ Create a debian/openstack-dashboard.triggers that would contain a > list of "interest /usr/share/javascript/<something>", for example: > > interest /usr/share/javascript/jsencrypt Please *always* consider using the -noawait (deb-triggers(5) and dpkg-trigger(1)) variants if the triggering packages does not depend (at “dpkg” time) on the functionality provided by the trigger, as it simplifies the trigger handling and should avoid most possible trigger cycles due to that. > Is it *that* simple? I'm surprised by the "interest" thing just being > hinted with a directory. Does this mean that if anything changes in that > directory, then there's a trigger, and the openstack-dashboard compress > stuff will happen? Anything changed below that directory should activate the trigger, as long as it is either known to dpkg, or something activates it manually through dpkg-trigger(1). On Tue, 2014-12-02 at 15:23:21 +0100, Thorsten Glaser wrote: > On Tue, 2 Dec 2014, Brian May wrote: > > There might be times when compress is run twice. e.g. when > > It does, yes. I wonder about that too. Can a package trigger itself? It _can_ (as in it is possible), but depending on how it is done that *might* produce trigger cycles. > > (e.g. you could explicitly raise the trigger inside the configure event, > > however that will trigger all applications that have an interest > > in /usr/share/javascript/jsencrypt which is probably not desirable) If your only intention is to avoid duplicated work, then yeah that might defeat it by shifting the load somewhere else. > Maybe otherwise: both postinst and the /usr/share/javascript/jsencrypt > trigger handler trigger a 'openstack-dashboard-meta' trigger, which > does the actual work? All triggers for an interested package are coalesced, and doing the above would most probably create a cycle. You'd only need to activate an explicit (private) trigger from the configure, and that would get coalesced with any file triggers, which should avoid the duplication you are seeing I guess. (Well as long as I've understood correctly what you are trying to achieve. :) Thanks, Guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141203162539.ga15...@gaara.hadrons.org