Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 592234 - rpm exits 0 on scriptles failure
Summary: rpm exits 0 on scriptles failure
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: rpm
Version: 6.0
Hardware: All
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: Panu Matilainen
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks: 747123 756082
TreeView+ depends on / blocked
 
Reported: 2010-05-14 10:13 UTC by Paolo Penzo
Modified: 2018-11-26 19:09 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 569930
Environment:
Last Closed: 2013-05-16 16:25:48 UTC
Target Upstream Version:


Attachments (Terms of Use)
A patch for legacy compatibility (deleted)
2010-11-15 16:23 UTC, Paolo Penzo
no flags Details | Diff

Description Paolo Penzo 2010-05-14 10:13:43 UTC
The same issue as in the cloned bug.

Comment 2 RHEL Product and Program Management 2010-05-14 12:04:14 UTC
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.

Comment 3 RHEL Product and Program Management 2010-05-14 13:15:57 UTC
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.

Comment 4 RHEL Product and Program Management 2010-07-15 14:25:39 UTC
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. **

Comment 6 Paolo Penzo 2010-11-15 16:23:55 UTC
Created attachment 460567 [details]
A patch for legacy compatibility

Comment 7 Panu Matilainen 2010-11-18 15:37:39 UTC
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.

Comment 8 RHEL Product and Program Management 2010-11-18 15:54:53 UTC
Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request.

Comment 9 Paolo Penzo 2010-11-19 22:10:49 UTC
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.

Comment 10 Chris Williams 2011-02-24 18:50:24 UTC
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.

Comment 14 Bryn M. Reeves 2011-05-05 14:16:52 UTC
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

Comment 16 Paolo Penzo 2011-05-06 07:19:21 UTC
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.

Comment 18 Bryn M. Reeves 2011-05-06 15:29:46 UTC
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".

Comment 19 Paolo Penzo 2011-05-10 18:46:23 UTC
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.

Comment 20 Bryn M. Reeves 2011-05-13 16:23:51 UTC
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.

Comment 28 devzero2000 2011-11-22 17:04:27 UTC
(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


Note You need to log in before you can comment on or make changes to this bug.