It has value of its own and can be used standalone;
autologin does require autostart though.

Adjust x11 feature targets accordingly.

Hardly belonged there in the first place and became a culprit
during armh branch development since it had to be forked in
an ugly manner; move to rootfs hooks and be done with it.

VM images will be able to benefit either *but* installed systems
might have some trouble when this is implemented:
http://lists.altlinux.org/pipermail/devel/2013-May/197447.html

Split off use/live/x11 as a common free/proprietary ground either
(this refactoring had to be performed in parallel with x11 feature
being revamped, diffs quickly became intertangled unfortunately).

This has had several goals:
- a target suitable for x86 and armh providing a rather
  minimal set of base xorg packages and generic drivers;
- task-oriented targets for graphics use cases:
  + "desktop" means rather 2D focus with 3D being welcome
    or even essential but not performance critical, thus
    "a slower driver is fine as long as it does work";
  + "3d" means specific 3D performance being critical,
    that is "no 3D means no use at all".

Regarding the free and proprietary 3D-capable drivers:
the previous idea was to split out some common ground
and then add the contenders on top of that; the current
approach is based on the observation that the live images
requiring proprietary NVIDIA/AMD drivers *by default*
are usually of not much use with hardware that lacks
proper 3D acceleration (like Tseng cards) or the driver
support for that (like Matrox these days).

Intel videodriver makes for a special case though:
it is both free and top-notch performer.

Thanks sem@ and boyarsh@ for discussion.

PS: xorg-drv-{keyboard,mouse,void} dropped;
those who need these can usually help themselves.

These handle only VE-like products (think TWRP on Nexus 7);
the proper image support should be backported later on.

An experiment in layered configurations is still in its
early stages regarding ARM zoo...

The feature officially introduces the "engineering passwords"
including empty ones which have been around since forever but
weren't properly managed (and still are not, at least until
there are no stray passwd/chpasswd/usermod calls in both the
profile, installer-features and all the other related parts).

It is based on an m-p-d init3-users script by stanv@ but was
cleaned up and restructured in a pretty severe manner; thanks
glebfm@ for additional discussion.

This also cleans up the kludge previously stuck into build-vm.

Note that vm/icewm sports graphical autologin now as well as
the default root password (which can be overridden by passing
ROOTPW=... to make but it is a change from the previous state
of affairs indeed).

This one is finally there and should help reduce the
systemd-induced mess in package lists and specifications.

The issue is that use/fonts/infinality doesn't actually
require the script hook thus registering the feature's
name in FEATURES variable so that the feature's contents
get copied over is not neccessary (distcfg.mk build-up
will have happened anyways).

But that's confusing if one's forgot this peculiarity
(like me today) or never knew of it, so let's spare
some frustration.

This feature is more generally applicable indeed;
might result in duplication due to the installer
components adding "efivars" independently but that
is to be sorted out later in those components:
- check whether it's added already sometime soon;
- maybe stop adding that at some point in the future.

install2 and rescue roots still need this too though.

This feature should be more generally applicable indeed.

Classic VEs don't carry any kernel since these are running
under a single OpenVZ (or potentially LXC) kernel image;
ARM Multiboot (TWRP in this particular case) allows to boot
off a chroot via kexec, and we need a kernel in it for that,
obviously.

No bootloader required inside such VE though.

This subprofile is akin to THE_* variables family: the configuration
bits and script hooks sitting there influence whatever chroot is
declared to be the user facing one in the end, whether it comes
from vm image or live subprofile.

The services feature ought to be a changeset of its own which would
be based on rootfs and become the base for ve/vm changes but I chose
to just do it atomically; some pre-existing duplicates are pruned now.

- 1.0

The script would work nevertheless (given the feature's included)
but lapses are especially wrong in examples.

- 1.0pre

These have been proofread somewhat to correspond
to the current state of affairs; a missing one
was added for fonts feature.

Not as clean as it should be unfortunately,
main.mk has to be reworked to drop the crap...

Looks better indeed, thanks cow@.

...and switch to cinnamon-regular metapackage in general:
the remaining blocker being gdm required by that and not
actually going to work (it used to start gnome-shell which
wouldn't work in that configuration either) is now fixed,
thanks cow@.

PS: plymouth is moved upstream, drop the dup.

- +installer

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.

A simple server image has been a pretty popular request
roughly always; thanks asy@ for specification draft.

There were several packages which don't really belong to base
list but rather to the desktop one; given that both of these
are included in desktop images it's a no-op for them but the
server ones might be better off without graphics.

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.

Commit g2b975e1b got it wrong for server-regular as it turns out now,
at least until that image decides to support LUKS either.

There was no real reason to use/cleanup/x11-alterator downstream
every time instead of promoting it upstream to the common point.

...so that they can run mtr, iftop and other goodies out-of-box;
thanks folks at forum.altlinux.org for a regular-icewm.iso
related feature request.

The installed livecd would lack fstab entries for the filesystems
other than those mounted explicitly during partition step; while
this might be considered either bug or feature, let's try that
and see.

Whoops: XFS, JFS, NTFS, FAT support has been lost while dancing
with reusing rescue lists and back to being lean.

Thanks Vladimir Gusev for spotting [a part of] this.

Thanks cow@ cinnamon is back in Sisyphus thus in regular builds;
the old gdm3/plymouth issue seems gone just as with gnome3 flavour.

- more regular fixes

The temporary problem between gdm and plymouth
seems gone, just get this back.

shaba@ says it's improper yet as prefdm is used (#28973).

Another service that's not very useful on a LiveCD;
maybe should be enabled by default upon installation,
this also requires a proper framework in place.

Thanks shaba@ for the bugreport:
http://lists.altlinux.org/pipermail/sisyphus/2013-May/360713.html

- regular fixes