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 965567 - yum --assumeyes assumes missing packages are OK
Summary: yum --assumeyes assumes missing packages are OK
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: yum
Version: 6.4
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Packaging Maintenance Team
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-05-21 11:17 UTC by Ian Wienand
Modified: 2014-12-04 10:33 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-12-04 10:33:33 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
example log of missing packages (61.76 KB, text/x-log)
2013-05-21 11:26 UTC, Ian Wienand
no flags Details

Description Ian Wienand 2013-05-21 11:17:41 UTC
Description of problem:

I noticed this when trying to get devstack working on RHEL6.  It uses "yum -y" to install a big list of packages to deploy openstack.

These packages have lots of dependencies, which we want to bring in.  But there are also possibly some missing packages, which we would like to stop the build for (devstack testing runs in a CI job, so if somebody is working on Fedora, say, and accidentally adds a package that is missing on RHEL, the build should break).

So --assumeyes is required for installing the dependencies in an automated fashion.  However, this also assumes that missing packages are OK.  I can't see any option that would allow, in an automated fashion, the installation of dependent packages but halt on missing packages.

One option may be to install every package individually and halt when one does not work, rather than in a big, single command.  This would be terribly slow, however.

An option to not prompt for satisfied dependencies but still error out when packages are missing would be very welcome.

Comment 1 Ian Wienand 2013-05-21 11:26:35 UTC
Created attachment 751054 [details]
example log of missing packages

Comment 2 Zdeněk Pavlas 2013-05-21 14:17:36 UTC
This is unrelated to the --assumeyes option.  Currently, when at least one of the requested packages could be processed, Yum assumes it's okay.  Otherwise, a 'Nothing to do' error is printed.  If you didn't specify --assumeyes, Yum wouldn't stop with an error either.

In this case, a "all or nothing" should be better.  Unfortunately, there's no "strict" mode switch in yum.conf, and I don't want to adding one just for this specific case.  It's easy to use --assumeyes to bend the rules instead.
I could live with that, but it's a hack, needs discussion.

diff --git a/cli.py b/cli.py
index 8c61ffd..db301be 100755
--- a/cli.py
+++ b/cli.py
@@ -910,12 +910,14 @@ class YumBaseCli(yum.YumBase, output.YumOutput):
             except yum.Errors.InstallError:
                 self.verbose_logger.log(yum.logginglevels.INFO_2,
                                         _('No package %s%s%s available.'),
                                         self.term.MODE['bold'], arg,
                                         self.term.MODE['normal'])
                 self._maybeYouMeant(arg)
+                if self.conf.assumeyes:
+                    return 1, [_('Nothing to do')]
             else:
                 done = True
                 self._install_upgraded_requires(txmbrs)
         if len(self.tsInfo) > oldcount:
             change = len(self.tsInfo) - oldcount
             return 2, [P_('%d package to install', '%d packages to install', change) % change]

(and dtto for update, downgrade, remove, reinstall).

Comment 3 James Antill 2013-05-28 18:35:56 UTC
> Currently, when at least one of the requested packages could be processed, Yum assumes it's okay

 Changing this is a bad idea, unless we make it some option ... which is probably a really bad fix for this particular case.

> One option may be to install every package individually and halt when one does not work, rather than in a big, single command.  This would be terribly slow, however.

 I doubt it's much slower, yum depsolving isn't the fastest in the world but it's rarely that slow. However if it really is too slow then one workaround would be to do a big install and then use "yum list installed foo" (which is very fast) to check that they are installed.

> An option to not prompt for satisfied dependencies but still error out when packages are missing would be very welcome.

Adding another option for this corner case doesn't seem that great.

I can think of a couple of other solutions:

1. Use load-ts ... this can be configured to fail when packages aren't found. But requires a specific format.

2. Use alwaysprompt=false. This requires that no extra deps will be needed though.

3. The thing which generates the list of packages instead creates a group or a metapackage, and installs that (in the former case it being easy to see if the group is installed or not, in the later the transaction will fail).

...if those aren't good we can look at adding something else (maybe a special "yum shell" like command where each install/install-n/remove/etc. has to succeed?).

Comment 4 Attila Fazekas 2014-08-15 08:29:44 UTC
2. does not solves the issue
1,3 over complicated.

IMHO yum has to provide a simple way for reporting installation issues, when multiple package requested in a single command. (non zero exit status)

Most people expects if a command has partial failure it reports failure at the end by default. (like make, cp ..)

Basically if any action item what would fail the command as a single action item needs to fail the command when multiple action item defined.

What about adding --strict=[yes,no] option, which gets its default value from the yum.conf. --strict=yes would mean consider partial success as failure,
and it would try to operate in "all or nothing" fashion when it is possible.

I would recommend also adding a '-Y' option which would be a short hand equivalent for '--assumeyes --strict=yes'.

Comment 6 Jan Zeleny 2014-08-15 09:10:07 UTC
How critical is this on RHEL6? Seems to me like a nice to have feature that is not exactly blocking anything (workarounds exist, as pointed out in the bug description and comment 3). To explain here, we have to minimize the number of features that go into yum as close to zero as possible, as we have only a limited capacity to implement them.

Comment 7 Valentina Mukhamedzhanova 2014-12-04 10:33:33 UTC
I'm closing this for the reasons stated in comment 6.


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