Re: porting spec files

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



On 07/10/16 10:17, Alice Wonder wrote:


On 10/07/2016 01:44 AM, Ned Slider wrote:
On 06/10/16 22:50, Alice Wonder wrote:
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?


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.


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.

Probably better to have the file trigger conceptually, less chance for
scriptlet bugs, but CentOS 8 will come soon enough I suppose ;)


_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos



[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux