Bug 965567

Created attachment 751054 [details]
example log of missing packages

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).

> 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?).

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'.

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.

I'm closing this for the reasons stated in comment 6.