Porting Spec Files
An rpm intended for a bleeding edge Fedora builds perfectly for me when I comment two macros apparently not in CentOS 7 –
%transfiletriggerin
and
%transfiletriggerun
Looks like they operate similar to %post and %postun but are different.
Is a simple way to do what they do in CentOS 7 or do I have to change the packaging logic to build in CentOS 7 and have things work properly?
3 thoughts on - Porting Spec Files
These are file triggers, they trigger scripts to run when specific files are added or removed from the system when packages are (un)installed. See here:
http://www.rpm.org/wiki/FileTriggers
Whilst RHEL’s version of RPM doesn’t support file triggers, it does support package triggers, so maybe you could devise a workaround with those:
http://rpm.org/api/4.4.2.2/triggers.html
Okay it looks like what is happening is the triggers are used when plugins are installed, and the CentOS 7 way is to run those triggers in the post/pre scriptlets of the packages that have the plugins.
Probably better to have the file trigger conceptually, less chance for scriptlet bugs, but CentOS 8 will come soon enough I suppose ;)
Yes, that is the preferred method and is OK as long as you also have packaging control over the packages that provide the plugins. The point of the file triggers is for when that is not the case.
Generally, triggers should be used sparingly (as a last resort) as they have a tendency to complicate matters rather than simplify, and thus make troubleshooting issues much harder.
For example, you package some software that needs to do something every time the kernel is updated. You don’t have control over the kernel package, so you use a trigger in your own package – either a package trigger if the action needs to be performed every time the kernel package is (un)installed/updated, or a file trigger if it’s when a specific file is (un)installed/updated.
The reason it makes things hard to troubleshoot is that, using the example above, the kernel is updated and that triggers your script in package Foo and something goes wrong. You’ve narrowed it down to happening every time you update the kernel package so naturally you now spend an age going through the kernel SPEC file trying to find the cause but of course you are looking in the wrong place and will never find it.