Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
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.
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 2RHEL 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.
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 6RHEL 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. **
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.
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.
(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 14Jan 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.
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 16RHEL 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.
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.
see upstream commit ce2ce4c19724879b9ea469e7760c7922660b9698
May be add macro to make this behaviour configurable to not trip up other API users (than yum).
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.
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
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.