RPM Community Forums

Mailing List Message of <rpm-users>

Re: How would one extract the trigger scripts from a spec file.

From: Jeff Johnson <n3npq.jbj@gmail.com>
Date: Thu 13 Oct 2011 - 00:20:44 CEST
Message-Id: <E87C59D8-286A-4591-AA3E-EF994A35B635@mac.com>

On Oct 12, 2011, at 4:36 PM, James Olin Oden wrote:

> I figured out that there are a bunch of tags with TRIGGER at the
> begining of the name that form some set of parallel arrays of
> information on all the triggers:
> 
>   TRIGGERFLAGS
>   TRIGGERINDEX
>   TRIGGERNAME
>   TRIGGERSCRIPTPROG
>   TRIGGERSCRIPTS
>   TRIGGERVERSION
>   TRIGGERCONDS
>   TRIGGERTYPE
> 

You've mixed in some header tag extensions with
actual tags that are present in packages.

The extensions are there to make it easier to use
--queryformat to display trigger scripts, not anything
deep.

Triggers have:
   1) a "firing" condition
   2) a script and interpreter to run when "fired"

> In my case I just want to run the scripts through bash -c and validate
> that there syntax is good, and show the information on the script.

Likely
	rpm -qp --triggers *.rpm | 
into a script is the easiest path for a bash -c syntax check.

(aside)
Note that the same syntax check is automated by
invoking bash --rpm-requires @rpm5.org (and with triggers
as well iirc). The back port likely isn't hard, and it is as easy
to use "bash -c" as it is to do "bash --rpm-requires" if desired.

The goal would be better automation: fail the build on scriptlet syntax errors.

> However I can't seem to locate the scripts, and I figure the "name"
> would be a concatenation of the trigger name an d the type, but I'm
> not sure how to interpret the type.   I can dig into the source and
> figure this out, but before that can anyone point me to a quick
> explanation of the tags involving triggers or could they explain them?
> 

The basic change for RPMTAG_TRIGGER* tag storage is merely this:
	For most scriptlets packages <-> script relation is 1-to-1.
	But there can be multiple triggers in a single package so the
	the store is 1-to-N (i.e. one package can have multiple triggers).
The TRIGGERINDEX is "glue" to make 1-to-N possible (and also handles
the various types of triggers which are distinguished by bits in *FLAGS.

(aside)
I used to think it was a good idea to move all scriptlets into a storage
like used by triggers to reduce clutter in the RPMTAG_* name space.

Then along came LSB demanding "standard" compliance for no real purpose
and it became infeasible to change anything at all in RPM without also
attempting parallel change to LSB "standards" and politcs took over 

*shrug*

Holler if you have a specific question and I'll look at code.

hth

73 de Jeff
Received on Thu Oct 13 00:20:54 2011
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.