> * Non-trans scriptlets have should get a second argument reflecting the
> triggering package count
I wonder if we want the triggering package count (`arg2`) to be an *aggregate*
count of all the triggering packages or just that of the *first* match?
There's a subtle difference in the semantics between regular triggers and file
triggers in the way they are fired. A regular trigger can only ever be
triggered by *one* package (e.g. `%triggerin -- foo, bar, baz` means "fire if
any of these packages is installed"), whereas a file trigger can be triggered
by *multiple* packages (e.g. `%filetriggerin -- /etc/foo.d` means "fire if any
file with such a prefix is installed, regardless of which package it belongs
to").
In both cases, the trigger only executes once, however the semantics of "which
package triggered it" differs. Therefore, for regular triggers, `arg2` is
straightforward (it's always the one triggering package), however for file
triggers, it's not.
As an example, consider the following scenario:
```
# bar.spec:
%filetriggerin -- /etc/foo.d
# foo.spec:
%files
/etc/foo.d/foo.conf
# baz.spec:
%files
/etc/foo.d/baz.conf
```
If `bar` is installed first, installing `foo` or `baz` afterwards results in
the trigger being run once for *each* of those, so the triggering count
(`arg2`) is straighforward (same as with regular triggers).
However, if `foo` *and* `baz` are installed first, installing `bar` afterwards
results in the trigger being run once for *both* of those (with both filenames
served via stdin), so the trigerring count (`arg2`) is now ambiguous - it can
either be the count of `foo` *or* `baz`, or it can be the sum of both.
My take: The count should be an aggregate since that enables a file trigger
script to detect when *all* the files subject to the prefix are being removed
(which is one of the purposes of the arguments in the first place).
Any thoughts?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2755#issuecomment-1878388267
You are receiving this because you are subscribed to this thread.
Message ID: <rpm-software-management/rpm/issues/2755/1878388...@github.com>
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
