When attempting to check if a package exists for a particular provide string
what happened is if an older version of the package was on the system but a
newer version in the repositories then the older (system) version would be
returned by dnf provides, but this could not be translated into a package name
with dnf repoquery because that specific version could not be found in the
repos. The solution was to check rpm first to translate the package name on the
system and then dnf repoquery if rpm doesn't find it.
This brought to light issues when passing arrays of package names to rpm and dnf
which might happen to contain an empty element. In this case rpm and dnf would
consider the empty arg an indicator that it should match all packages on the
system, or all available packages. While we should try to avoid passing arrays
with empty elements, this highlighed a need to make rpm and dnf safer in this
regard, and so there are now saferpm and sfednf functions which simply strip any
empty args before calling the appropriate command with the rest of the args
untouched.
This commit also fixes an issue with output column formatting.
Changed variable names to lowerspace
Added doublequotes to variable usage
Converted opts to an array
Doublebrackets instead of [ ]
Changed to printf instead of echo for logging
Added force to rm
Before this commit, the Rocky system packages like rocky-repos,
rocky-release and similar, were not checked for their gpg signature,
while the rest of the packages were signature checked.
While the system packages were downloaded from https://dl.rockylinux.org,
this still created the risk that someone could attack the CDN infrastructure
behind dl.rockylinux.org and place malicous files there.
With this patch the GPG key is downloaded separately and then compared
against a checksum contained in the script. This adds an extra layer of
security.
Before this commit the user was supposed to give the -e cmdline parameter
to run the EFI conversion when necessary. But it was missing in the getopts
parameter list, so it didn't work.
Instead of fixing it, I opted to remove the -e parameter alltogether and
automatically detect if the system is running on EFI or not. Because if the
user should forget to give -e on an EFI system, it would result in an unbootable
system without any bootmanager installed. Fixing this situation takes time and
requires some sysadmin skills, so we should take steps to avoid this situation.
Detecting if the system runs on EFI or not can reliably done by checking for
/sys/firmware/efi/.
This is for two reaons:
1. There have been a number of complaints about the color blue. For now I
can't get reasonable agreement on which color to make informative messages and
it will differ depending on what the background color is of a person's terminal.
2. Currently the log is generated simply by splitting stdout and stderr. That
means that color codes go to the log, which is less than ideal. We need
separate logging routines that don't send the color codes but for now turning
off color will suffice.
This has been accomplished simply by commenting out the tput assignments at the
beginning of the script. It is likely that osme form of color support will go
back in at some point so we'll keep the old code around for now.
EL 8.0 had a dnf that was not compatible with this script (output changed
causing parsing errors). Make sure that e ahve a recent enough dnf for this
script to run properly and recommend updating otherwise.
