Why are they there?

5.18 kernel uses CONFIG_DRM_SIMPLEDRM as its base framebuffer.

This packages needed on UEFI Secure Boot for diagnostic.
Suggested-by: nikel@

For riscv64 available grub-efi.
Needed added support for mkimage (mki-copy-efiboot-chrooted).

CONFIG_EFI_VARS is deprecated, and removed for aarch64 (Linux >= 5.10.0).

A space in the THE_PACKAGES list makes it impossible to install
the system.

$$(EFI_BOOTLOADER)) is a bootloader for STAGE1 only.

Module efivars will be loaded by udev now.

This is necessary to prevent unintentional assignment of rEFInd
as EFI_BOOTLOADER.
I also want to hope that memtest86.efi can be made to work from
grub-efi in the future.

Signed UEFI loader not required for aarch64.

NB: i586 images don't need UEFI SB either
and 32-bit shim is used for x86_64 images
along with proper 64-bit one.

These got removed from Sisyphus during OpenSSL 1.1 transition.

Those few places lacking "; @:" replacement for a real recipe
have been finally -spotted- identified with `make check'
and fixed.

THE_* variables serve user needs while shim belongs
to either SYSTEM or COMMON level packages, not needed
explicitly for stage1 though (mkimage will put it there
when needed) so it's just COMMON.

It's been missing roughly from the start there :-/

It's not supported anymore:
http://git.altlinux.org/tasks/archive/done/_133/136193/

The newly-introduced STAGE1_KCONFIG variable serves
to keep those kernel configuration options that are
required to be present in the kernel to boot.

That reflects the packaging and distribution practice
having formed during last year or so...

This change is done to reduce ambiguity in some cases;
the previous intention has been to ease navigation when
staying in a particular directory, now it's been changed
in favour of convenient toplevel `git grep' in fact.

Both variants have their pros and cons, I just find myself
leaning to this one by now hence the commit.  Feel free to
provide constructive criticism :)

Some path-related bitrot has also been fixed while at that.

I've noted that this bit of code should be fixed up
before pushing but managed to overlook that in the end :(

mkimage version bump is due to the somewhat changed layout
of EFI packages and binaries within those (linked message in Russian):
http://lists.altlinux.org/pipermail/devel-distro/2013-December/001283.html

It's at least as worthy as sbsigntools are.

It's implemented just like EFI_SHELL and will definitely
change someday but so far it's like this...

We chose to provide methods to sign packages but to avoid
signing these by default (with some arbitrary test keys)
the signatures are being added *after* the build by means
of rpmrebuild-pesign; all of this is made significantly
more complicated if there are separate -signed subpackages.

So these are being dropped in the packages; account for that.

This feature is more generally applicable indeed;
might result in duplication due to the installer
components adding "efivars" independently but that
is to be sorted out later in those components:
- check whether it's added already sometime soon;
- maybe stop adding that at some point in the future.

install2 and rescue roots still need this too though.

Bump it to account for the useful fixes in mkimage-0.2.7.

It's possible that use/efi/signed target has fired already
at the time when use/efi/shell is invoked; shouldn't clobber
the signed shell with unsigned one.

Its support is quite mature and practically useful by now.
Let's also add a convenient alias.

Helps with #28470 (FAT not being recognized) which is critical
due to ESP being FAT by spec :-/

Thanks timonbl4@ for the hint.

Was an oversight to miss it.

It's aimed at providing UEFI shell implementation which is very
useful for repairs and debug; if the "signed" mode is requested
then the signed variant is used either.

Please note that there are two distinct uses:
- a shell lying around on a filesystem to be copied by hand;
- a shell available in EFI part of boot media to be launched
  by firmware's or standalone boot manager (e.g. refind).