@pmatilai converted this issue into discussion #2754.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1370#event-10899590184
You are receiving this because you are subscribed to this thread.
Message ID:
Ran into this old issue while browsing around...
> Speaking of file trigger issues: what's the deal with the
> %transfiletriggerpostun triggers? Why are they not fed a list of matching
> files so they can check if there is really something to do?
Hmm? AFAIK they should behave like the other
Speaking of file trigger issues: what's the deal with the
%transfiletriggerpostun triggers? Why are they not fed a list of matching files
so they can check if there is really something to do? And why is the
implementation so weird? I don't see any reason for that
> That's not true if the package containing the trigger is installed/erased
> (the so called "immed" case). Here, the trigger is called with a set of files
> coming from multiple packages.
In that case the triggering package is the package containing the trigger.
--
You are receiving this
> The problem with counting owners is that it's a per-file thing, and a
> file-trigger can match any arbitrary number of them, so the count would have
> to be per-file and so can't be in the global argument. I should've just
> dropped both the global arguments while at it...
The documentation
The problem with counting owners is that it's a per-file thing, and a
file-trigger can match any arbitrary number of them, so the count would have to
be per-file and so can't be in the global argument. I should've just dropped
both the global arguments while at it...
--
You are receiving this
(Just FYI: libzypp will support posttrans file triggers soonish. So you could
use that to do the info install after the uninstall.)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
At least for `%filetriggerun`, the hardcoded `0` as argument actually makes it
really dangerous to use properly, as it is also run when the package containing
the trigger is uninstalled/upgraded from. The issue is that the
`%filetriggerun` is called after the new package's `%filetriggerin`, so
zypper calls the rpm command. So a new transaction for each package..
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
s/zypper/zypp/
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1370#issuecomment-701263659___
Rpm-maint mailing list
Hmm, that seems strange. I get that with zypp doing multiple smaller
transactions (IIRC), the transaction triggers would execute more often than
just once, but since there will inevitably be far fewer partial transactions
than packages, it'd still seem beneficial to do the expensive cache
zypp installs rpms individually and disables transaction scripts:
https://bugzilla.suse.com/show_bug.cgi?id=1041742
If a script knew why it was called it could probably decide to ignore the
"useless" calls. Like eg by passing more arguments. Legacy scripts would not
use them and continue to
Not sure what you mean by Zypp not supporting transfiletrigger, all the (file
or otherwise) triggers are implemented inside librpm and the only thing an API
user such as Zypp can do about them is to explicitly disable
(RPMTRANS_FLAG_NOFOO)
Triggers lacking arguments is well known, but ...
Trying to implement file triggers for mandoc to register and unregister man
pages in the whatis database I ran into some strange behavior. Note I can't use
transfiletrigger as zypp doesn't support that :(
- triggers are executed several times on upgrade and uninstall for the same
package (ie
14 matches
Mail list logo
