Available for mipsel too.

In make-initrd >= 2.5.0-alt1 feature usb requires kernel modules optional.

This features not needed for auto-detect.
We also add features not only to initrd.mk, but also specify them
explicitly in the command.

Kernel flavours differ on secondary arches (and there's a bunch
of platform-specific kernels for ARM systems), so let's provide
some more flexible scheme than hardwiring un-def into images.

This might be further enhanced to e.g. set KFLAVOURS to
$$(KFLAVOURS_LATEST)) with it being preset to un-def
where available so rpi images could set it to rpi-un,
and still get reasonable starterkits for free.

The corresponding commit in RELENG-e2k-p9-starterkits
private branch just tore un-def apart => unmergeable.

xhci-plat-hcd needed for USB boot on Raspberry Pi 4B
dwc2 needed for USB boot on Raspberry Pi 3B, 3B+

VM_INITRDFEATURES qemu not allowed for e2k only. This feature
added modules optionaly.
VM_INITRDFEATURES usb allowed for all arches, but the presence of all
modules is required. Therefore, for all arches all usb modules are
optionally added.

The entry in /etc/fstab about the mount parameters of the root
partition needs to be done not only for builds with u-boot.
But, if the record already exists, then it will not be added.
The file system type is set by the variable VM_FSTYPE.

Since packet sorting is enabled by default, then
the order in KFLAVORS has ceased to matter.
Kernels are always installed in alphabetical order.
Therefore, it makes no sense to sort by buildtime.
See-also: https://bugzilla.altlinux.org/show_bug.cgi?id=30806

Also fixed my typo. When creating a symlink, the variable
$kver was used, i.e. the entire list of kernels, not the
last value $KVER of the list.

ahci_platform needed for Baikal M.
Suggested-by: Sergey Bolshakov <sbolshakov@altlinux.org>

aarch64 repo has got std-def/un-def flavours by now.

NB: 07-kernel change breaks multi-kernel setup!

Breaks: 650e92bf

This might evolve into some form of per-arch logic,
or otherwise x86 might get moved into a feature of
its own instead of being the presumed one.

The first step is done.

It's apparently needed for ALT Server and has been
used implicitly for server-pve starterkit.

Looks like a thinko by now...

KFLAVOURS could have been set earlier and got overridden here.

This has been borrowed from m-p-d for Centaurus, actually.

It's unreasonable for firmware to depend on kernel,
the features should go in the other way around.

Maybe firmware feature should be merged into kernel feature
as the firmware binaries added by it are only used by kernel
but let's clean up a bit at a time.

It conflicts with r8169.ko inobviously.

The whole mess looks like this:
- r8169.ko doesn't work for all of Realtek 8111/8168/8169 mutations
- r8168.ko works with some of the chips r8169.ko doesn't
- r8168.ko also works with many chips r8169.ko works with
- r8169.ko is provided by kernel-image package (thus default)
- r8168.ko is provided by kernel-modules-r8168 package (optional)
- kernel-modules-r8168 package requires r8168-blacklist package
- r8168-blacklist package is a one-liner that blacklists r8169.ko
- STAGE1_KMODULES wouldn't include r8168 (std-def) or rtl8168 (led-ws)
- sub.in/stage1/modules would mention r8168.ko (m-p-d: r8169.ko)

So a LiveCD built with use/kernel/net might work with RTL8111/8110
just fine when booted live but fail to automatically load the module
when installed onto hard drive; manual modprobe r8169 would work though.
NB: some of the chips (those available to me) would work just fine
both ways -- this has contributed to fixing this *that* late.

Bottom line:

  do not install backup/kludge drivers overriding main ones by default!

Thanks sem@ for providing the crucial hint.

The various *8168 and friends among kernel modules
have finally been pushed into a designated target
so that RM doesn't have to care which particular
additional ethernet modules are available in this
particular branch and kernel.

Tweak distros as appropriate.

NB: *maybe* this is required by distro/.base either.

It wasn't spotted when introducing the distinct kernel feature;
will need fixup as we meet packaged ARM/PPC kernels.

un-def was a desperate measure when std-def of the day
was suddenly plain broken.

This reverts 0e8871e7.

3.5.2-std-def-alt2 brings boot problems which were absent
with 3.4.x-std-def and are absent with 3.5.x-un-def;
seems like it's better to stay with known good variant
at the moment instead of having to fall back to it.

This further refines the modular build by making
metadata being a clearly separated feature rather
than having to rely on runtime tests, and also by
moving the code which cares for kernel bits of base
installation (.base list) in a feature of its own.

There's more to it but let's get the ball rolling first.