installFromYum: give more detailed error messages on gpg errors

[ydirson]

This is a complement to the gpg-checking feature enabled for 8.3.

This is a continuation of #68 which got closed when xs8 was destroyed and cannot be reopened (thx github).

Covers:

1. repo_gpgcheck:
   a. wrong system clock putting gpg key creation in the future, causing a yum crash (nothing special happens if the date of the signature is in the future ¯\_(ツ)_/¯)
   b. other yum crashes due to uncaught gpg exceptions (if any)
   c. lack of repomd signature (while repo_gpgcheck is in force)
   d. signature done by other key than the one in ISO ("repomd.xml signature could not be verified" ¯\_(ツ)_/¯)
2. gpgcheck:
   a. RPM signed with unknown key
   b. unsigned RPM referenced by unsigned repomd (no-repo-gpgcheck)
   c. RPM re-signed with unknown key, unsigned repomd (no-repo-gpgcheck)
   d. RPM overwritten with another RPM signed with known key (diagnosed through hash but, same diag as 2.c)
   e. delsigned/resigned/etc RPM, unchanged repomd (same diag as 2.c/d)

Does not cover notably:

• unsigned RPM referenced by (re)signed repomd

In some cases Yum does not give an error, but dies because of an uncaught exception, which makes this check quite brittle, but in the worst case if messages change, we still fallback to the original "Error installing packages" message.

[alexbrett]

What is the purpose of defining these variables and then raising the ErrorInstallingPackage exception later - could we not simply raise the exception directly at the point we find something in the log?

[ydirson]

I cannot recall precisely, but:

• (likely original reason) to keep the structure of the existing code; notably, there was already an exception raised with a generic message, and all that needed to be changed was the message
• in line with that, it allows to keep the "yum exited" log, which would have to be duplicated, or wrapped with the exception in a helper (and delegating the raise to a helper function causes its own problems)
• additionally it allows to make sure to use the most pertinent message, regardless of the matching order, which in turn is constrained by the order in which strings appear. Maybe not really necessary for this set of messages, but considering this is ad-hoc parsing of a program's output, including parsing of its crashes, it may be useful to retain this flexibility

[freddy77]

Why instead of using a lot of flags variable you don't just set a string variable errmsg to save the specific error and use it? You could initialize it at default generic message and change accordingly based on the specific error.