This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.

This issue has been proposed when we are only considering blocker
issues in the current Red Hat Enterprise Linux release. It has
been denied for the current Red Hat Enterprise Linux release.

** If you would still like this issue considered for the current
release, ask your support representative to file as a blocker on
your behalf. Otherwise ask that it be considered for the next
Red Hat Enterprise Linux release. **

Created attachment 460567 [details]
A patch for legacy compatibility

NAK, the behavior is intentional, and the suggested patch has far more consequences than just rpm -Uvh exit code. 

I would suggest using yum for the installations (even if the packages are local) instead of rpm commandline. Yum maintains a history database for all operations, including warnings, outright failures and even scriptlet output, so you have much much more information available than one byte of data which cannot even begin to encode what happens in a potentially very large transaction.

Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request.

You may think this is a bug, as I do, or just an underestimated side effect of the new RPM API, this does not really matters. Anyway treating errors in %post* scripts as normal conditions breaks the rpm/yum/yumex (and so on) backward compatibility which is not acceptable in an Enterprise environment since there might be, as in this case, many software relying on this feature.

The patches I've submitted are not intended to just handle the exit code of the command "rpm -Uvh" but to revert the RPM API behaviour on errors in %post* scriptlets as it was in releases before 4.6. 
These patches, simply changing the %_ignore_post_scripts_errors macro, allows you to handle these errors in the new or in old way, the shipped rpm library does not.
If you do not like my approach you can implement a better one but, I think, backward compatibility must be retained and the yum developers have at least the same doubt as I do (see comment at last line of rpmtrans.py in yum 3.2.27/3.2.28 code).

At the end the proposed alternative approach (parsing yum history output) is error prone and less reliable than just checking the return code of rpm -Uvh.

This bug was not resolved before development freeze.  We are now making preparations for the launch of 6.1 and are only accepting critical and high impact bugs.  We're reflagging this bug for 6.2 to continue the review and work needed to resolve this bug.

How about a hackish wrapper script? E.g. something like:

$ cat ~/bin/rpm-backspin.sh 
#!/bin/bash
rpm "$@" 2>&1 | grep '^warning.*scriptlet failed' && exit 1
exit 0

This "Works for Me" in my (limited) testing:

# rpm-backspin -Uvh --force sos-2.2-8.el6.noarch.rpm
# echo $?
0

# rpm-backspin -ivh samplerpm-0.0-0.noarch.rpm
warning: %post(samplerpm-0.0-0.noarch) scriptlet failed, exit status 1
# echo $?
1

This script could be a workaround for a closed source software but this is not the case indeed. 
Anyway since it's based on grep there are, IMHO, two issues:
1) the installation stderr and stdout get lost and cannot be logged elsewhere.
2) the script real return code is not considered and a script like this
 echo "warning: a simple way to check if a scriptlet failed"
 exit 0
will give a false positive.

As far as I can see the correct way to address this issue is simply to return the 
scriptlet return code with the usual meaning, 0 on success or not 0 on error.
However, if simply reverting to this won't be possible, to deal with both the old way and the new behaviour rpm should use a configuration macro, as I did in my patches, or use a command line switch.

It's not the case but it is the case that the workaround may be deployed immediately with only supported distribution components. It was an effort to be helpful and of course you are not bound to use it. However you may if you wish.

1) That was "left as an exercise to the reader"; I did not want to clutter the simple example with unnecessary cruft. It is however trivially added and I would be quite happy to supply such a version if really required.

2) I understood we were talking about spec file typos. I reall think this is a rather unlikely typo ;)

I do not disagree about correct ways and although I do not speak for the RPM team upstream or at Red Hat I don't think they do either however there are real and practical constraints on making API visible changes in already released products. "One man's fix is another man's regression".

I apreciated your effort but a similar script still depends too much on the result of the grep command and must set LANG=C which might lead to other issues for the software under installation.

If LANG=C breaks the package being installed then the package has a bug. Locale set during RPM transaction should have no effect on the installed software.

(In reply to comment #14)I am sorry but perhaps you could be 
interested in what have done other implementation http://rpm5.org/community/rpm-users/0834.html

Regards


> How about a hackish wrapper script? E.g. something like:
> 
> $ cat ~/bin/rpm-backspin.sh 
> #!/bin/bash
> rpm "$@" 2>&1 | grep '^warning.*scriptlet failed' && exit 1
> exit 0
> 
> This "Works for Me" in my (limited) testing:
> 
> # rpm-backspin -Uvh --force sos-2.2-8.el6.noarch.rpm
> # echo $?
> 0
> 
> # rpm-backspin -ivh samplerpm-0.0-0.noarch.rpm
> warning: %post(samplerpm-0.0-0.noarch) scriptlet failed, exit status 1
> # echo $?
> 1