RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 606239 - Need rpm API to collect scriptlet output from %posttrans
Summary: Need rpm API to collect scriptlet output from %posttrans
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: rpm
Version: 6.0
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Packaging Maintenance Team
QA Contact: Karel Srot
URL:
Whiteboard:
Depends On:
Blocks: 582655 771912 1076076 1159721 1159824
TreeView+ depends on / blocked
 
Reported: 2010-06-21 07:56 UTC by Šimon Lukašík
Modified: 2015-07-22 07:01 UTC (History)
9 users (show)

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.
Clone Of:
Environment:
Last Closed: 2015-07-22 07:01:01 UTC
Target Upstream Version:
Embargoed:

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


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:1452 0 normal SHIPPED_LIVE rpm bug fix and enhancement update 2015-07-20 18:43:47 UTC

Description Šimon Lukašík 2010-06-21 07:56:42 UTC 
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 Program Management 2010-06-21 08:23:23 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 James Antill 2010-06-21 14:40:02 UTC 
You don't get anything on the screen or in history, right?
Comment 4 Šimon Lukašík 2010-06-21 21:35:32 UTC 
Yes, I don't get anything on the screen (and history) compared to `rpm -ivh foo*`.
Comment 5 Panu Matilainen 2010-06-23 06:52:07 UTC 
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 Program Management 2010-07-15 14:25:34 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 7 Eduard Benes 2010-11-19 15:09:06 UTC 
I guess this was meant to be filed against yum -> reassigning
Comment 8 James Antill 2010-11-19 15:19:06 UTC 
No, Eduard, read the comments.
Comment 9 Panu Matilainen 2010-11-22 17:44:16 UTC 
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 Logcher 2011-03-28 21:09:07 UTC 
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 18:36:47 UTC 
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 06:24:59 UTC 
(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 (Red Hat) 2012-01-06 14:49:19 UTC 
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 10:00:26 UTC 
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 Program Management 2012-05-03 04:35:48 UTC 
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 22:32:35 UTC 
this bug blocks fedora bug 615763
Comment 18 Florian Festi 2012-08-02 09:51:31 UTC 
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 14:53:02 UTC 
Reopening so yum can fix 1076076
Comment 20 Florian Festi 2014-12-16 14:40:30 UTC 
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 08:06:37 UTC 
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 07:01:01 UTC 
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.