The builder-useradd package installs components of ALT build
environment into the system, namely gear, hasher, and git-core
required for those to work.

See commit 207cec89c4515fefa2b711acd06c645ed3bd0ee8.

KFLAVOURS can describe more than one kernel, get iterator back.

Fixes: 27674e29

- ppc64le support (glebfm@)
- build-vm hacked to build tarballs too (iv@ et al)
- p8.mk: dropped; along with other cleanups/fixups (antohami)

It was misleading already, and riscv64 is going to join the gang
(but not there yet) following aarch64, mipsel, ppc64le and more
e2k* subarches...

I've just borrowed glebfm@'s one introduced by commit
ec23a8ec before; this
still might be improved it seems.
Suggested-by: Gleb Fotengauer-Malinovskiy <glebfm@altlinux.org>

When grub-install(1) works on non-virtualized PowerPC system it may
execute scripts from powerpc-utils package.

ieee1275boot bootloader support was added in mkimage 0.2.27.

Plymouth is (much more) portable, but our branding packages contain
bootsplash designs only on x86 nowdays.

...to create users root:alt and alt:root as per BaseALT's rebranding.

This allows one not to hope that only the packages of the desired
loader will be installed.

Should be done this way in the first place it seems.

(gkebfm@ thinks it was a terrible idea in the first place
and mike@ agrees; this is a rework TODO item)

build-vm ceases to be a target for building only virtual machine images.
Now it can be used to build tarballs designed for installation on real
machines.

This commit is the result of transferring the required functionality from
build-mr (mipsel rootfs) by Ivan Melnikov <iv@altlinux.org>.

NB: mike@ strongly objected to this dilution but gave up eventually;
    the whole kernel/build-vm/tar2fs/pack mess should be split into
    distinct layers busy with their own responsibilities:

    1) a tarball with kernel is done without tar2fs at all
       (and no build-vm bits should be needed either, maybe
       it's worth splitting and renaming as "vm" meaning
       disk image for some armh board is grossly misleading);

    2) a tarball with kernel can be further (multi-)packed
       as, well, (compressed) tarball and a disk image
       (only the latter one should employ build-vm/tar2fs);

    3) compression should be done in pack feature style,
       preferably described once and not duplicated all over
       the profile for every single new kind of its output.

    In the mean time, running into this and moving no further
    starts to hurt more than it could help.