Re: [Rpm-maint] [rpm-software-management/rpm] file trigger quirks (#1370)
@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: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] file trigger quirks (#1370)
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 triggers, if not then it sounds like a bug. > And why is the implementation so weird? I don't see any reason for that > rpmtriggersPrepPostUnTransFileTrigs() function, all it does can also be done > at the end of the transaction. At the end of the transaction where posttrans really runs, the packages that would match are already be gone and the triggers would never run at all. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1370#issuecomment-1689435129 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] file trigger quirks (#1370)
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 rpmtriggersPrepPostUnTransFileTrigs() function, all it does can also be done at the end of the transaction. -- 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-759335642___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] file trigger quirks (#1370)
> 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 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-758575444___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] file trigger quirks (#1370)
> 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 says: "File triggers execute once for package". So unlike `%transfiletrigger`, plain `%filetrigger` is called once for each triggering package (including itself, for all matching installed files), so there is a single triggering package for each call. In the case that the triggering package is completely removed (`$1 == 0`), there's a potential issue with files owned by multiple packages, but arguably `%postun` has the same. In this particular case, only the case that `%filetriggerun` is called for all files when the package containing the trigger is upgraded is an issue, which currently can't be detected. Though I currently wonder why `%filetriggerun` is not called when a package with matching files is upgraded. That might just be a case of no (clear) documentation, as if it were called, the script couldn't tell and probably undo the work of `%filetriggerin`. -- 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-758563971___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] file trigger quirks (#1370)
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 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-758555027___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] file trigger quirks (#1370)
(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: https://github.com/rpm-software-management/rpm/issues/1370#issuecomment-758036737___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] file trigger quirks (#1370)
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 it
overrides and practically reverses what `%filetriggerin` did.
e.g.
```
%filetriggerin -- %{_infodir}
...
install-info $file
%filetriggerun -- %{_infodir}
...
install-info --delete $file
```
After an upgrade of this package, every file in `%{_infodir}` gets
unregistered. Currently I can't think of a proper workaround, other than
creating and checking a flag file.
--
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-758021866___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] file trigger quirks (#1370)
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: https://github.com/rpm-software-management/rpm/issues/1370#issuecomment-701263564___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] file trigger quirks (#1370)
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 Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] file trigger quirks (#1370)
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 updates etc there. As for arguments, no argument there. "Just" a matter of designing and implementing something sane in that space, together with bunch of other semantics fixes/clarifications etc that real-world usage has pointed out to minimize disruption. -- 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-701259736___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] file trigger quirks (#1370)
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 function. -- 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-700574842___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] file trigger quirks (#1370)
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 ... shockingly seems there's no upstream bug for that :flushed: , just this: https://bugzilla.redhat.com/show_bug.cgi?id=1301677 I could've sworn we moved that to here ages ago but apparently not. The multitude of filetriggerin-runs comes from both the installed and the in-transaction package triggering, once for the existing files and once for the files in the transaction. I'd call this stuff file trigger design flaws, somewhat hard to fix now that it's widely deployed (typical chicken-egg situation: hard to develop such stuff when nobody is using it when it's experimental, hard to change flaws after declared stable so people would use it) -- 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-699971865___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] file trigger quirks (#1370)
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 the package with the trigger itself)
- the argument is always zero. So the triggers cannot handle upgrades
differently.
- the triggers do not know the package a file belongs to. In case of mandoc
installation that would be helpful as it could then just rebuild the database
to speed things up instead of calling it on single files. Similar on erase it
would just do nothing and wait for rpm to remove the database later.
```
tw:/root # rpm -q rpm
rpm-4.15.1-7.2.x86_64
tw:/root # cat filetriggers.spec
Name: filetriggers
Version:1.0
Release:%{?rel}%{!?rel:1}
%define nvr %{name}-%{version}-%{release}
Summary:Testing file triggers
Group: testing
License:GPL
BuildArch: noarch
%description
%{summary}
%install
install -D -m 644 /dev/null %buildroot/usr/lib/foo/1
install -D -m 644 /dev/null %buildroot/usr/lib/foo/2
%filetriggerin -- /usr/lib/foo
echo "filetriggerin %{nvr}: $@"
cat > /dev/null
%filetriggerun -- /usr/lib/foo
echo "filetriggerun %{nvr}: $@"
cat > /dev/null
%preun
echo "preun %{nvr}: $@"
%files
/usr/lib/foo
/usr/lib/foo/1
/usr/lib/foo/2
tw:/root # for i in 1 2; do rpmbuild -bb filetriggers.spec --define "%rel $i";
done
[...]
tw:/root # cd /usr/src/packages/RPMS/noarch/
tw:/usr/src/packages/RPMS/noarch # rpm -U filetriggers-1.0-1.noarch.rpm
filetriggerin filetriggers-1.0-1: 0
tw:/usr/src/packages/RPMS/noarch # rpm -U filetriggers-1.0-2.noarch.rpm
filetriggerin filetriggers-1.0-1: 0
filetriggerin filetriggers-1.0-2: 0
filetriggerin filetriggers-1.0-2: 0
filetriggerun filetriggers-1.0-1: 0
preun filetriggers-1.0-1: 1
tw:/usr/src/packages/RPMS/noarch # rpm -e filetriggers
filetriggerun filetriggers-1.0-2: 0
filetriggerun filetriggers-1.0-2: 0
preun filetriggers-1.0-2: 0
```
--
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___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
