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

...so that enp0s3 is just not there.

Maybe it's worth moving to the kernel feature as well.

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.

Let's make CPU microcode an explicit target, it isn't
required at every host where firmware-linux is.

Adjusted its use accordingly.

Richard and Theo would probably roll their eyes at this point
but the unfortunate reality is that wireless hardware is very
much dependent on firmware being explicitly provided; so here
it is.

rtl8192 kernel module added since it's present in t6/branch
at least.

Pretty natural but delayed somehow...

UEFI support is pretty requisite by now;
and el-smp hasn't seen updates for almost
half a year by now so an actively maintained
one is clearly preferred.

Some images were unbuildable (at least without special setup,
like ve/centos), unusable or just not useful in any meaningful way
(like distro/live-isomd5sum); as these tend to get any attention
during experiments, I decided to put them together in a separate
configuration file that would be effectively skipped if DEBUG
is not requested.

Essentially all the relevant server images got cpufreq setup
and a power button handler; feel free to ask for revert if
this causes any harm in any situation.

Also pulled the pkglist/kmodule part out of distro/server-mini's
recipe and started off a standalone feature based on it.

NB: el-smp kernel now contains aufs as a module but propagator
doesn't try to modprobe it.

There's no need to repeat the typical openssh-* triade
all over the place; those who need server and client
are better off pulling in "openssh" pkglist, and those
needing a particular package should specify it.

(mike@: actually no sense to set both
KFLAVOURS and STAGE1_KFLAVOUR to the same value
since the latter is derived from the former)

It doesn't really need WiFi support so far,
and when it does the feature should be done
properly (along with setup tools at least).

There's no real reason to keep bcmwl and ndiswrapper
around exclusively as the currently available support
vastly takes over the early attempts at the task.

(it's not about bare firmware though, and some day
something like use/hardware/wireless should get in)

A very basic server image with sshd onboard for testing
and very basic installs; thanks legion@ for the query.

- incompatible change (to fix the rather broken early style):
  use/syslinux/ui-% is now use/syslinux/ui/%;

- default timeout changed to 9 seconds (long enough and keeps
  the countdown in a single figure);

- added totaltimeout of 300 seconds;

- provided live kiosk images with almost-instant boot by default;

...and some other assorted tweaks here and there, sorry.

Mostly multiline compactions, but also use/install2/net
got factored out from distro/server-ovz for future reuse.

As noted in doc/assumptions.txt, the SHELL based target tracing
only works for rules with recipes, even empty but present ones.

The simplest thing to do is hooking "; @:" onto the rule's tail
(one-liner with a non-printing shell builting "true" command).

There are pseudo-distro targets that are useful to combine
the needed bits and pieces for a few more different end-user
images but that are useless themselves (e.g. desktop-base
wouldn't even start X session before someone would have
installed a window manager).

Let's just hide these under the hood so that `make help',
`make everything' and potential frontends don't bother.

There's still an annoying problem (a race?) manifesting itself
as installer bailing out between packages installation and lilo
setup with X segfault in logs; while the culprit is not known yet,
let's avoid that for most images by moving the bootloader request
from the former "leaf" target (which noe became a "node") into an
experimental server-systemd one.

Thanks Leo-sp50 for bringing that to my attention again; see also
http://forum.russ2.com/index.php?showtopic=3310&pid=31364&st=0&#entry31364

As was duly noted by Leo-sp50, both server.mk and desktop.mk
duplicate a few bits layered over bare distro/installer which
happened to be both a dependency (thus should reduce redundancy)
and a "real distro" target (well, it doesn't just work yet, need
to provide networking and sources.list in install2 by hand).

Fixed by moving a "node" to distro/.installer along with typical
additions and leaving a bare installer as is by now; there's a
need to get it working at least for DHCP/ftp.altlinux.org case.

This is to fit base/extra separation better
and to avoid lvm2 creeping into VE images.

As too many things started duplicating between distros proper
and (e.g. corresponding) LiveCDs, it became apparent that a class
of entities which end up working for THE_USER (not a sysadmin,
and not a developer, just a Linux user) is in need.

So THE_KMODULES will power installed basesystem and live image,
while THE_PACKAGES, THE_LISTS and THE_GROUPS will participate
in building those.

distro/.base target used to pull in localboot syslinux config
snippet which might be too early for some of the further distros;
it's a quite fragile equilibrium which was shifted a bit by imz@
(see #26606).  Feel free to reopen the discussion though, things
might be tweaked so that localboot might be desirable on almost
every image even if with lower priority...

It's now possible to:
- make distro/server-ovz.iso;
- make distro/server-ovz-netinst.iso;
- publish the former image's contents on ftp.linux.kiev.ua;
- boot the latter (~17M) image and enjoy the netinstall ;-)

The catch is that the stage2 (altinst file) location has to be
hardwired into syslinux config snippet for things to happen
automatically -- even if it can be specified manually in case
of failure.

The other catch is that currently a netinstall image is somewhat
tied to the particular image it installs since stage1 kernel and
stage2 modules must correspond strictly (the typical symptoms of
the glitch would be missing mouse driver and weird "permission
denied" errors during an attempt to partition the hard drives).

It might be desirable to provide multi-distro netinstall image...

The culprit was missing dhcpcd, although the rest
of niceties already in server-mini were welcome to
server-ovz either.

We've got some parts of it in build-distro feature,
and some went to dev feature for no real reason.

But a bare installer might go without package base,
and LiveCDs other than live-builder might find local
repository useful given aufs2 root overlay.

Now the overall scheme is more straightforward:
- a distro:
  + asks that a package repo be included
  + cares to further add the packages to it
- a repo feature:
  + pulls in sub/main for it to happen
  + provides genbasedir script to create repo metadata
  + supplements live feature with repo configuration

Thanks shaba@ for both the package and a wiki page,
and dek@ for the inspiration to finally get to it.

This feature was handling powersave already, so the name
should be changed already.  Thanks sem@ for cpufreq-simple,
there's now a compelling reason for that rename.

Tweaked a few distro recipes accordingly.

This was asked for by Leo-sp50 and torabora, and seems quite reasonable:
let's provide means to keep at least some distribution configurations
a bit apart, so that these can be considered more standalone in terms
of hard warranted functionality but at the same time enjoying the common
infrastructure.

Considering lib/distro.mk: it's now experimentally pulled apart so that
parallel development of different distro families can go on without
major merge hassles.  *Please* don't abuse with massive copy-paste.

And before you ask: this might get extended to allow for "private"
out-of-tree configurations being included since apparently there
are goals with no meaning outside of some very particular context...
but otherwise I'd like to encourage getting reusable bits in-tree.