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

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.

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

UEFI shell is pretty valuable debugging and fixup tool.

When one has to mess with Restricted Boot, openssl and
some PE signing tools might come handy either; see also
http://www.rodsbooks.com/efi-bootloaders/secureboot.html

Its bootloader autodetection capabilities can prove quite useful;
this particular addition has been "sponsored" by this thread:
http://lists.altlinux.org/pipermail/sisyphus/2013-January/subject.html#359481

mkimage > 0.2.5 should have received enhanced UEFI support
including the ability to setup refind (#28349);
make the feature ready for that.

The implementation goes the shim[1] way as described here[2];
many thanks to Matthew Garrett and Rod Smith.

[1] http://mjg59.dreamwidth.org/20303.html
[2] http://www.rodsbooks.com/efi-bootloaders/secureboot.html

The rescue feature intentionally doesn't pick up THE_PACKAGES
and THE_LISTS into stage2, so add EFI ones explicitly.

There's a possibility to run into IA32 EFI but that's rather
uninteresting hardware (ancient Xeon servers and <s>outdated</s>
early Intel Mac laptops).  Just drop it on the floor.

As x86_64 UEFI support would result in "2D hybrid(r)(tm)" image
which boots with all combinations of BIOS/UEFI by CD|DVD/Flash
(or at least should boot), some downgrace seems due: use/efi will
turn use/isohybrid on non-x86_64 -- which will require further
tweaks on PPC/ARM some day.

The initial approach required some quite involved postprocessing
as described in http://www.altlinux.org/UEFI#HOWTO; after having
ironed out the kinks so that initial EFI support could be merged
into mkimage proper we're better off just using it, eh?

EFI/UEFI is mostly about partitioning and bootloader setup,
at least from a distribution's point of view; so the
appropriate tools should be handy and firmware interface
module should not be exterminated from installer images
but get autoloaded instead.

Please note that while there exists 32-bit x86 EFI
we don't bother with it at the time being: it's relevant
to some irrelevant Xeon systems as well as for the older
Intel Macs (<2008) that are long out of fashion anyways.
That is, initially we deal with x86_64 EFI only.