The line containing @KFLAVOUR is expanded into several lines,
it is successively replaced with values from the KFLAVOURS variable.
This will allow to specify kernel modules and kernel headers in lists.

lilo is stagnating, it is better to prepare in advance for the fact
that it will not exist.

The idea is to not embed grub.cfg in the efi image, in order to determine the
installed grub in EFI/BOOT/boot*.efi by grub.cfg.
In the case of x86_64, the prebuilt uefi image is always used.

Both UEFI and Legacy BIOS are supported on x86_64 machines. Now the
image x86_64 will be bootloaded on both.

grub-efi-autoupdate does not update grub in EFI/BOOT if there is
no shim and EFI/altlinux.
See https://bugzilla.altlinux.org/41959

Use a prebuilt grub image for EFI, creating BOOT/EFI/grub.cfg

Fix for commit c11a9ca11b550ed916999fe2fa45def59bc94e22
Reported by andy@

Fix 'warning: fgrep is obsolescent; using grep -F'

Fix 'warning: egrep is obsolescent; using grep -E'

This will save time on identify the causes.

There's a race condition (TOCTOU) between losetup --find
and applying the obtained path after additional dd in between;
twice awful as *at least* running both losetups closely would
reduce the window significantly, and reading the manpage
properly back then would eliminate this.
Reported-by: Anton Midyukov <antohami@altlinux.org>
Suggested-by: Gleb F-Malinovskiy <glebfm@altlinux.org>

...just to have it handy when it's in need next time.

"-a arch" is not requisite either; and having bunches
of empty lines in the resulting pkglists that are user
visible at least within the conventional installer's
alterator-pkg (groups selection) module wouldn't be nice.

I chose to sacrifice empty-line separators for clarity;
the really good cleanup would save *single* empty lines
between chunks of non-empty ones (not at the pkglist's
start or end); feel free to implement that as well.

This has been clearly lacking while making the previous commit
but the implementation isn't that clear so let it be a separate
step.

The problem requiring the change in subsequent processors
is that these relied upon "@arch" as a flag to be inspected,
and "pkg@!arch1,arch2" on arch2 needs to take out *all* of that
fragment *including* arch1 mention as well.

Part of the cause is difference in handling: "positive" multi-match
would explode its "client" line into multiple lines to filter down
the pipeline, while "negative" multi-match *has* to keep that line
on a similarly single line (otherwise we'd end up with N-1 of those
slipping past the filter for particular architecture thus defeating
the whole purpose of "negative" matching semantics):

$ echo 'pkg@!E2K,mipsel,riscv64' |
  sed -r  ':loop; s/^((([^@]+@!)[^,]+)+),([a-zA-Z0-9_]+)/\1@!\4/; t loop'
pkg@!E2K@!mipsel@!riscv64

I've tried my best to test this specific change but it still might
introduce a regression in some corner case; feel free to report;
looks like there's a space for improvement in m-p's automated
tests department as well.

So now we can do:

  pkg@!ARCHES1,ARCHES2,arch3,arch4

and have pkg excluded on arches mentioned; the previous approach
could only offer explicit whitelists (not that it was entirely
wrong but then again, we have both ExclusiveArch and ExcludeArch
rpmtags in our spec files).

This has been inspired by a few commits that cared
for package availability reasons on a particular
architecture; the problem at hand is that pkglists
might need to include groups of packages that are
(un)available on groups of arches, and tackling that
with plain pkg@arch just results in combinatorial
explosion of that matrix.

Arches are handled one-by-one with a few hardcoded
macro substitutions.

Exploding a "pkg@arch1,arch2" string into a set of:

pkg@arch1
pkg@arch2

with subsequent archdep pruning would do the trick;
so here's another sed oneliner that does just that:

$ echo 'pkg@X86,ARM,ppc64le' |
  sed -r ':loop; s/^((([^@]+@)[^,]+)+),([^,]+)/\1\n\3\4/; t loop'
pkg@X86
pkg@ARM
pkg@ppc64le

See-also: 9601a9e7
See-also: 5581dc91
See-also: http://stackoverflow.com/a/55781741/561921

This space is reserved for installation U-Boot.

Parameter "legacyboot" causes an error:
parted: invalid token: legacyboot

There is little use, but a lot of noise.

Unavailable metapackages will be removed from the list.
A warning will be displayed in the log.

Booting from extlinux.conf is preferred over booting in EFI mode.

This space can be used by single board for u-boot.

The @META suffix is used to expand the metapackage into a list.
apt asks for the dependencies of such a package and adds them to the
package list after this metapackage.

The missing glob resulted in disk images properly
partitioned only for e2kv3 ("e2k" for historical
reasons in ALT), and v4+ ones only got a single
ext4 partition that wouldn't work with current
MCST's Boot code.

os-probe finds loopback devices.

While this argument can only have one "EFI" value.
Thus, the problem of building an image for Raspberry Pi on armh,
where there is no grub-efi, was solved.

extlinux.conf is not tied to the u-boot bootloader and always
needed replace Label with the UUID if the file exist.

Since the main goal for aarch64 and armh for us is Raspberry Pi,
it is always worth creating a fat32 partition for these arches.
At least for now.