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

From: Isaac Dunham <[email-masked]>
Date: Fri, 22 Jan 2016 20:39:43 -0800

Hello,
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?)

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.

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.

Thanks,
Isaac Dunham

---
Unsubscribe:  [email-masked]
Help:         [email-masked]
---

---

From: Timo Teras <[email-masked]>
Date: Sat, 23 Jan 2016 23:09:00 +0200

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

> 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
arguments.

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.

> 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.

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.

> 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.

@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?

/Timo

---

---

From: Natanael Copa <[email-masked]>
Date: Mon, 25 Jan 2016 08:51:31 +0100

On Sat, 23 Jan 2016 23:09:00 +0200

> > I'm wondering what causes triggers to run.

...

> @ncopa Do you think we have triggers that'd break if we add the

No, I don't think any triggers would break if we add match for deleted
files. I think all triggers we have so far only watches directories, so
we should be good.

> modify, delete) fire the trigger?

With the above you could easily detect if its deleted or add/modified.
I would think that is enough for most cases? I suspect that you will in
almost all cases want to handle 'modified' the same way as 'add'.

If this shows to not be enough, then maybe add that via env var in
future or similar?

-nc

---