Mail archive

Re: [alpine-aports] Exactly when do triggers run?

From: Timo Teras <>
Date: Sat, 23 Jan 2016 23:09:00 +0200

On Fri, 22 Jan 2016 20:39:43 -0800
Isaac Dunham <> wrote:

> I'm wondering what causes triggers to run.
> Specifically, it seems that a trigger only runs if the watched
> files/dirs are changed *by another package*.
> Is this expected behavior, or a case of a situation not being
> expected? (Or is it simply that the trigger does not exist during the
> package upgrades?)

Trigger should run when ever package contents touch a file matching
trigger specification. When the package with trigger itself gets
installed or upgraded, the trigger is fired with all matching files
(in package database).

The trigger gets list of matching files that were modified as

The triggers are run after all packages have been extracted and files
moved into the correct positions. The list of triggers to run is
calculated, and the triggers are sorted based on the package dependency
order. Finally the are executed serially.

> In case you're wondering what I'm trying to do:
> I've built ted with both GTK (/usr/bin/Ted) and Motif
> (/usr/bin/Ted.motif) versions.
> I'd like the Motif version to automatically get a link to it if
> there's not already a /usr/bin/Ted binary.
> This should happen even if I do
> apk add ted
> apk add ted-motif
> apk del ted
> I've been trying to do this thus:
> ted-motif provides ted
> ted-motif has a trigger watching /usr/bin/Ted*
> The trigger never goes off.

Yes, your watch is for the specific file; and deletion of the file does
not fire it currently.

For busybox the symlink magic works because busybox monitors
the /usr/bin path.

> Experimenting, I see that "provides=$PKG" doesn't work like I thought;
> it results in $PKG being replaced.
> So it should work to simply install Ted.motif as Ted.

Currently file deletion does not fire trigger if the match is for the
file. It does however fire if the match is against a directory.

I suppose the above could be considered a bug. It would make more sense
to fire the trigger, and give the deleted file as argument and leave it
up to the trigger to figure out that the file does not exist anymore.

_at_ncopa Do you think we have triggers that'd break if we add the
match for deleted files?

Or should there be specific syntax on which type of events (add,
modify, delete) fire the trigger?


Received on Sat Jan 23 2016 - 23:09:00 UTC