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.

This one has filled up the entire 8 Mb tmpfs
while running inside installer stage1 on a
124-drive system (configured as JBOD).

Reported-by: http://norsi-trans.ru

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

Kernel packages we have on this architecture use
uncompressed vmlinux file called image; handle that.

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.

This function's got its argument order chosen for "aesthetical"
reason of $(2) following $(1) in the macros but the logical order
is exactly the opposite: we care for kernel flavour much more than
for module set (which is dependent upon it).

So while silent dropout of kernel-image if KFLAVOURS is set
but KMODULES is empty could be fixed by testing for $(2) only,
it looks like a good time to fix this discrepancy altogether.

stage2 has been thinking it's synonymous with propagator
and used to usurp kernel's belongings either; carefully
tear scripts apart so that kernel feature makes sure
initrd gets generated, and stage2 (which is still all
about propagator) cares for its bits.

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.

An initial draft of it was done half a year ago but several tricky
thingies had kept the code from showing up as it was rather brittle
and incomplete.

This implementation involves quite a few changes all over the place
but finally works good enough for live and installer images.

Please pay attention to the versions of these packages:
- installer-feature-setup-plymouth (0.3.2-alt1+)
- branding-altlinux-sisyphus (20110706-alt2+ if used)
- plymouth (0.8.3-alt20.git20110406+)

See also:
- http://www.altlinux.org/Branding
- http://www.altlinux.org/Plymouth

Shame on me, these shouldn't get forgotten in the first place.

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.