How to detect rpm post scriptlet failure

[Levon Poghosyan]

Hello,

How can I detect if the execution of post scriptlet of the rpm package
failed ?
I've generated the and rpm package which has a test command lalala in post
install section. So during the installation it prints out information that
command lalala was not found but the installation is still successful.
How do I identify this failure from post install section.

Please note I'm not interested in failure in other places, I just need to be
informed in post install scriptlet failed.

Regards,
Levon

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

[Jeff Johnson]

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



__
RPM Package Managerhttp://rpm5.org
User Communication List rpm-users@rpm5.org