...included by default in use/install2

Workaround ALT bug 35350 for install2.

IIRC it's actually looked for by EVMS fat plugin.

+installer should work everywhere it can at all,
but full-blown one is currently developed on x86;
provide at least the reasonable chunk elsewhere.

This adds mkfs.fat and fsck.fat utilities to installer
so it's able to create/mount this "filesystem" as well.

Not that it was critical here but rather to reduce bit rot.

See-also: https://lists.altlinux.org/pipermail/devel/2018-June/204486.html

It's needed for alterator-wizardface ported to guile22.
Suggested-by: Sergey Bolshakov <sbolshakov@altlinux.org>

libgpg-error and libgcrypt20 are apparently needed for current
systemd-tmpfiles which has been tossed into basesystem, alas.

See-also: https://lists.altlinux.org/pipermail/devel/2017-March/202518.html
See-also: https://lists.altlinux.org/pipermail/devel/2017-March/202527.html

Was broken in too many places including several libraries
x11vnc currently links against getting removed, several
utilities missing, and no way to guess what to do...

One could stumble upon http://altlinux.org/vncinst
or find the implementation in installer.git but it's
not exactly user-friendly.

Those few places lacking "; @:" replacement for a real recipe
have been finally -spotted- identified with `make check'
and fixed.

It's required for many touchpads these days,
just get it in for the "full" (+installer) target.

xorg-drv-vmmouse should accompany xorg-drv-vmware.
Reported-by: Anton Farygin <rider@altlinux.com>

This has been spotted by rider@ and reproduced by me as well:
some touchpads would work in livecd/installed system but not
within the installer itself.

The use case at hand was: "we'd better backup this system
to a flashdrive before installing" (given quad-core CPU
and half-terabyte HDD); pxz is pretty tiny, no worries.

use/install2/stage3 is only needed for distributions
implementing their own installer-*-stage3 package
(e.g., centaurus and simply but not kdesktop).

mixin/desktop-installer became *quite* inobvious
even for me over time, and it's not easy to grep up;
let's introduce explicit targets where one is expected
to expect those.

Signed-off-by: Aleksey Avdeev <avdeev@pkcc-tb.ru>

Commit 657c0bf6 has silently added use/bootloader
to the base use/install2 target thus breaking
experimental distro/netinst; it seems better to
require *a* bootloader in the target that's been
specifically designed to cover the common case
(thus linked to by +installer shortcut) but still
to have our base lightweight and flexible.

This doesn't hurt the actual distros as these use
+installer of course.

The corresponding installer feature had to be updated first
following blkid(8) output format changes, but that's it!

This has only been useful for plymouth feature,
and +installer shortcut included this target
for all the wrong reasons as it seems today
(thus blocking the DRM-free server installers,
for example).

This one uses an installer feature; should be reimplemented
using rootfs scripts carried over by installer some day.

This is the antagonist of the pre-existing cleanup;
suggested by frbrgeorge@ for starterkits.

led-ws kernel flavour has gained kernel-modules-vmware
recently, let's add this to the appropriate targets.

It's used in regular-jeos already but THE_ part was missing.

VMware specific bits went into use/install2/vmware target,
and all of those targets are worth their use/install2/vmguest
collective one instead of just sticking the kitchen sink into
use/install2/full immediately.

This one has been missing for quite some time (infiniband modules
should have triggered a commit like this back then), finally there
in very crude and draft form for the starters.

This destructive target is like a "people's revolution":
almost nothing left.

Some need this to achieve jeos or chaos, respectively.

...or are fine with fbdev like in case of installers,
especially minimalistic ones.

These are only needed for alterator-vm when making
LUKS encrypted partitions; ideally the extra libraries
would be omitted automatically when luks isn't included.

At least don't purge it with no questions answered.
Thanks naf@ for posting #29901.

This package has replaced installer-feature-setup-network-stage3
without declaring that; it appears that installer-distro-altlinux-*
don't require it even if most of the others do.

This is to ensure it's included, at least at the moment.

It's a tad pointless to be able to create a filesystem
but not to be able to fsck it at boot.

led@ has different kernel-modules-* package set,
some of those "standard" names are provided but
vbox* is not the case.

As our macros and helpers will grok this just fine,
let's add both variants so what's present gets in.

It's still inconvenient to discover mouse pointer
captured inside a box, let's overthrow the hardware
node and free it.

sub/main subprofile should not be requested directly
as documented in its README but rather via use/repo/main;
let's fix this discrepancy and check that no regressions
come hurling down.

INSTALL2_PACKAGES turned out to be sensitive to the
feature addition order: if efi was added before install2
then the packages added by the former were overridden
by the latter.

This is also related to commit g7b76c734 as +installer
can be added pretty much anywhere, there's no warranty
that use/install2 appears early enough in configuration
build-up sequence.

This one is a part of a larger rewrite to move away from
distro-centric build-up to configuration-centric one with
the particular packaging being of secondary importance
compared to actual functionality.

Thanks Serg Markov for bringing my attention to this:
http://www.opennet.ru/openforum/vsluhforumID3/86552.html#61

While the official distros might skip some filesystems for
support reasons there's no reason for community distros to
do so either.

Let's try that with icewm.iso...

NB: installer has a misfeature of dropping jfs/reiserfs
    support in runtime unless "expertmode" magic word
    is on the kernel bootargs string (#27763, #17368).

That sub/stage2/install2 was somewhat clumsy actually as it looked
like a hierarchical thing while being a substitution thing:
generic stage2 would get put in place renamed as install2.

This could only get worse with hierarchical features which have
already been both requested and considered for quite a time,
and "stage2 at install2" reads much more naturally.

A few too many downstream makefiles employed the pattern
of "export GLOBAL_VAR := $(VAR)"; macroize that.