[CentOS] porting spec files

Ned Slider ned at unixmail.co.uk
Fri Oct 7 10:11:04 UTC 2016


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 ;)
>




More information about the CentOS mailing list