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.

Spoils nouveau otherwise, see also
https://bugzilla.altlinux.org/show_bug.cgi?id=32340#c6Reported-by: Sergey Turchin <zerg@altlinux.org>

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!

The former install2-only "bloated binary" purge script
happened to hit stage2 (which is a lot more than just
install2); a kind of safety net has been stuck into it
to guard installable LiveCDs against this particular
cleanup but seems it was not enought for ildar@ who
reported this problem almost three years after it was
introduced.

This change re-places the script back into install2
section; the binaries in question amount for ca. 8 Mb
(except openssl ildar@ asked about); if these are deemed
unneccessary within any other stage2-based subprofiles,
please step up with details.

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.

It happens to hold couple of files nowadays
on an otherwise almost empty system!

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.

{lib,}bind shouldn't have to be removed twice, really.

By the time these hooks run the font packages' %post scriptlets
should have fired already; no need to carry the utilities on.

Yes these are bit-by-bit savings.  No it's too expensive still.

Both might be useful in some context but serve no real need
given the installer one, at least this year.

This rotten cherry-picking is ridiculous of course
but that's the price to pay for hard dependencies...

These aren't going to be really needed in that environment,
please refer to the more complete environments like rescue,
live, or an installed system.

xterm is pulled in by xinitrc (as xvt),
xdg-utils by alterator-browser-qt (for xdg-open).

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

My gut feeling is that we're not going to see glib2's
messages a lot within installer environment anyways.

And there's a forgotten /usr/share/X11/locale/ too.

These are required by no package after the intermediate
cleanup has finished.  Argh.

Installer doesn't do systemd and needs no service files.

An installer needs video playback acceleration
when it has some content to show and some means to;
as long as these are not supported just drop this
unconditionally.

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.