Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 606239 - Need rpm API to collect scriptlet output from %posttrans
Need rpm API to collect scriptlet output from %posttrans
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: rpm (Show other bugs)
6.0
All Linux
low Severity medium
: rc
: ---
Assigned To: packaging-team-maint
Karel Srot
: Reopened
Depends On:
Blocks: 582655 1159824 771912 1076076 1159721
  Show dependency treegraph
 
Reported: 2010-06-21 03:56 EDT by Šimon Lukašík
Modified: 2015-07-22 03:01 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Previously, the output of the %posttrans scriptlet was not correctly displayed to the user, which could lead to important errors being ignored. This update introduces a new API that collects the output from the %posttrans scriptlet. As a result, the yum utility can now access the %posttrans output, and displays it to the user.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-07-22 03:01:01 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
minimal spec, with %posttrans scriptlet (826 bytes, text/plain)
2010-06-21 03:56 EDT, Šimon Lukašík
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:1452 normal SHIPPED_LIVE rpm bug fix and enhancement update 2015-07-20 14:43:47 EDT

  None (edit)
Description Šimon Lukašík 2010-06-21 03:56:42 EDT
Created attachment 425558 [details]
minimal spec, with %posttrans scriptlet

Description of problem:
Output of %posttrans is hidden from user (compared to rpm). %posttrans itself is run, but output (even stderr) is ignored. Also applicable with maximum verbosity.
Output %posttrans is also not listed in `yum history list`.

Version-Release number of selected component (if applicable):
yum-3.2.27-12.el6.noarch

How reproducible:
always

Steps to Reproduce:
1. yum -d 30 -e 30 --rpmverbosity=30 -v -y  --nogpgcheck localinstall foo*
2.
3.
  
Actual results:
%posttrans output is hidden.

Expected results:
Similar to rpm, output listed. (if possible)

Additional info:
Output of other scriptlets is just ok.
Comment 2 RHEL Product and Program Management 2010-06-21 04:23:23 EDT
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 James Antill 2010-06-21 10:40:02 EDT
You don't get anything on the screen or in history, right?
Comment 4 Šimon Lukašík 2010-06-21 17:35:32 EDT
Yes, I don't get anything on the screen (and history) compared to `rpm -ivh foo*`.
Comment 5 Panu Matilainen 2010-06-23 02:52:07 EDT
Hmm okay... this is because rpm >= 4.7.x runs %posttrans by fetching headers from the rpmdb (the package is already installed at %posttrans) instead of re-re-re-opening the package file, and requiring you to keep the rpms around until the ts.run() completes. Which is a good thing... but the problem for yum's scriptlet output collecting is that no callbacks are currently issued for transaction element opens from the rpmdb. I remember adding a todo-comment to the sources about this but as there hasn't been practical need it just never got done.
Comment 6 RHEL Product and Program Management 2010-07-15 10:25:34 EDT
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 7 Eduard Benes 2010-11-19 10:09:06 EST
I guess this was meant to be filed against yum -> reassigning
Comment 8 James Antill 2010-11-19 10:19:06 EST
No, Eduard, read the comments.
Comment 9 Panu Matilainen 2010-11-22 12:44:16 EST
Conditional NAK: it's not clear how to sanely fix this. We don't want to go back to the state where %posttrans requires keeping package files around unnecessarily and re-opening the package at the end, and OTOH adding a new FYI callback which gets issued for all elements accessed from the database is a significant API change.
Comment 10 Suzanne Yeghiayan 2011-03-28 17:09:07 EDT
Since RHEL 6.1 External Beta has begun, and this bug remains 
unresolved, it has been rejected as it is not proposed as an 
exception or blocker.

Red Hat invites you to ask your support representative to 
propose this request, if appropriate and relevant, in the 
next release of Red Hat Enterprise Linux.
Comment 11 James Antill 2011-07-25 14:36:47 EDT
Eduard, why did you reassign this? Do you have a proposal on how I can fix this in yum alone?
Comment 12 Eduard Benes 2011-07-26 02:24:59 EDT
(In reply to comment #11)
> Eduard, why did you reassign this? Do you have a proposal on how I can fix this
> in yum alone?

You are right, sorry for that. Should be back to yum.
Comment 14 Jan Pazdziora 2012-01-06 09:49:19 EST
Setting this bug to be a blocker for bug 771912. Without %posttrans being able to show errors, RHEL users at EC2 can easily find themselves stuck with unusable systems after kernel upgrade.
Comment 15 Panu Matilainen 2012-03-02 05:00:26 EST
Upstream rpm has new callback event for scriptlet start and stop which *might* be reasonably backportable to rpm-4.8.x, but rpm internals in that area have changed a LOT, so backport feasibility needs closer evaluation. Supporting the new callback requires changes to yum as well and those changes dont even exist yet, there's no way to have this in rhel-6.3 -> moving to 6.4.

IF we end up backporting the new callback, we'll need to open a separate bug for the yum-side support.
Comment 16 RHEL Product and Program Management 2012-05-03 00:35:48 EDT
Since RHEL 6.3 External Beta has begun, and this bug remains
unresolved, it has been rejected as it is not proposed as
exception or blocker.

Red Hat invites you to ask your support representative to
propose this request, if appropriate and relevant, in the
next release of Red Hat Enterprise Linux.
Comment 17 Peter Backes 2012-05-30 18:32:35 EDT
this bug blocks fedora bug 615763
Comment 18 Florian Festi 2012-08-02 05:51:31 EDT
As upstream yum does not have code to make use of the callbacks backporting them does not make any sense right now. As soon as yum adds the support we can reconsider. Still the changes are extensive enough that they might be rejected for that reason alone.
Comment 19 James Antill 2014-03-27 10:53:02 EDT
Reopening so yum can fix 1076076
Comment 20 Florian Festi 2014-12-16 09:40:30 EST
see upstream commit ce2ce4c19724879b9ea469e7760c7922660b9698
May be add macro to make this behaviour configurable to not trip up other API users (than yum).
Comment 23 Ľuboš Kardoš 2015-02-26 03:06:37 EST
Added RPMCALLBACK_SCRIPT_START and RPMCALLBACK_SCRIPT_STOP. These events are not emitted by default only when macro %_accept_script_stop_start_callbacks is defined.
Comment 28 errata-xmlrpc 2015-07-22 03:01:01 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-1452.html

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