file trigger quirks

[lnussel]

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

[pmatilai]

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 😳 , 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)

[lnussel]

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.

[pmatilai]

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.

[lnussel]

zypper calls the rpm command. So a new transaction for each package..

[lnussel]

s/zypper/zypp/

[Vogtinator]

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.

[mlschroe]

The "proper" way would be to count the owners of the file, but calling rpm -qf from the scriptlet is somewhat frowned upon...

[mlschroe]

(Just FYI: libzypp will support posttrans file triggers soonish. So you could use that to do the info install after the uninstall.)

[pmatilai]

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

[Vogtinator]

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.

[mlschroe]

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.

[Vogtinator]

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.

[mlschroe]

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.

[pmatilai]

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. Of course if you look at it from the Zypper POV of doing one package at a time transactions, many things will look drastically different, but that's not how rpm is intended to be used.

[pmatilai]

Moved to a discussion because this is so open-ended. We'll create tickets for individual things when we know what exactly to implement.

[dmnks]

With the first argument to file triggers now implemented on master (as the number of instances of the triggered package to remain after the operation, much like with regular triggers), I wonder what the semantics of the second argument, if any, should be.

I've submitted a PR (#2883) adding arg2 that has the same semantics as the regular triggers, i.e. the number of instances of the triggering package to remain after the operation (also described here) but I wonder if that's actually practical. Any ideas?

[dmnks]

In any case, #2883 is now merged. We can always tweak this later, at least before the first public release carrying this feature.