- preparing for p8 starterkits

This single-byte error has led to premature variable
substitution thus non-existant "docs-" package being
requested; ouch.

live-privacy haven't graduated from beta status yet
but it's useful anyways; a bit of housekeeping
is due though.

gst-plugins-* was an /extremely/ bad and ugly idea indeed;
it pulled in every -devel it could.

This is to avoid "unzip.zip" situations with some NICs:
those needing extended firmware package (which is hefty)
can at least install it by hand off the ISO.

*Maybe* a switch to use/firmware will appear reasonable
some day for this image either, don't know yet; this adds
firmware to installer itself (should only be needed if the
storage device used for rootfs *needs* firmware found in
that package as networking setup is omitted from JeOS
installer).

Rationale: it's the minimalistic image for those who know
what they're doing, let's maximize their chances to get it
installed and running by using a recent kernel.

My failure to recognize that it is a "generic" server that
might need some generalization and not an already specialized
one like OpenVZ HN installer had to be fixed up some day;
today is fine.

Basically, let's move package groups ("checkboxes") and alterator
from server-ovz to server, and maybe beef it up a lil' bit more
later; server-ovz is still far from jeos-ovz but the difference
that looks unmergeable is strict sshd control setup that's going
to bite those unsuspecting, so let's leave it for those of us
who are more suspicious of stray ISOs. :)

Services and tools are clearly different entities,
and we need tools for a slimmer OpenVZ HN installer.

...to *not* error out if there's no gfxboot at all.

This pulls ConsoleKit in which isn't even operational by now...
Reported-by: Sergey V Turchin <zerg@altlinux.org>

A classic brown paper bag bug: this was typed in a hospital
and that commit was a sick one indeed, the condition should
have been the opposite.
Reported-by: Ildar Mulyukov <ildar@altlinux.org>
Closes: #31982

"Forensic mode" submenu has fallen apart after the original commit
as the tricky logic in mkimage::tools/mki-copy-efiboot failed to
pick up the new variant; this should all be redone (solo@ has
started doing something but it needs a time-consuming review).

Fixes: 79d02088

- pkg.in/profiles

This has been requested by Andrey Mitrofanov:
http://www.opennet.ru/openforum/vsluhforumID3/107265.html#162

Putting the image license text into its toplevel directory
is *very* reasonable as it's much more accessible then.

use/docs/license will copy the texts contained in branding
package ("notes" one) over to the image's rootdir so these
can be read with ease; otherwise one has to look up the
right package at best (or unpack squashfs, no user can be
really expected to do that just to *read* a *license*).

This was originally profiles/scripts.d/01-copy-license
script from m-p-d; got cut down heavily.

This one is just like STAGE2_BOOTARGS but for rescue images
(which don't do that one for quite a few reasons).

See the previous commit for rationale.

The problem at hand was that an installer component
of a "DVD class" image does use/cleanup/installer
while installable LiveCD component gets broken by that
(livecd-install -> installer-scripts-remount-stage2
which gets removed as installer-*).

Split those.

The same that was done by commit 50bfea9d.
Note the duplication, maybe worth to split off...

Mark the particular pkglists included into what's dumped;
makes content analysis considerably more convenient.

Failing to kaboom just in time can make (and has just made)
it harder to figure out the culprit down the road; e.g.
metadata target's tar(1) might fail to find *some* files
that haven't been copied over due to a single one missing
by that run.

Package profiles -- the ones allowing for a multi-purpose
installer -- have been basically overlooked during previous
mkimage-profiles development, unfortunately.

This is the very basic part: put them into pkg-groups.tar.

These are alike to lists/groups ones.

This is to support Centaurus-like images featuring
more than a single installation profile (e.g.,
"workstation/server/minimal").

Quite a few more modifications are needed to do it
right though as m-p has fallen prey to exactly the
"single root composition" assumption with its current
THE_* variables semantics and processing.

THE_* variables serve user needs while shim belongs
to either SYSTEM or COMMON level packages, not needed
explicitly for stage1 though (mkimage will put it there
when needed) so it's just COMMON.

DOTBASE variable setup has been superceded by metadata feature
(commit c83cc111); this reference is thus useless.

...regarding THE_* use.

...following another inspection of m-p-d's centaurus pkglists.

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

This has been borrowed from m-p-d for Centaurus, actually.

It's not reasonable for use/firmware/laptop to depend on
use/firmware/wireless as some laptops come without WiFi
cards and wireless userspace to use those is specified
elsewhere anyways.

It's unreasonable for firmware to depend on kernel,
the features should go in the other way around.

This might (and probably should) get split into
{base,desktop}+cups somewhere down the road,
maybe when we do print servers again; let's keep
things simple at the moment though, we only need
this for desktop images.

This one is required for HP MFP scanners to work;
note that setup is still quite peculiar (via cups/hpaio):
http://lists.alioth.debian.org/pipermail/sane-devel/2009-February/024117.html

This partially reverts commit 30d38381: trying to use/rescue
with e.g. distro/simply results in conflict between SysVinit
and systemd-sysvinit; INIT_TYPE had to relation to RESCUE_LISTS
in the first place.  Ugh.

This cp(1) option has been employed already but just for the lists
(and still incomplete as it didn't cover the names coming through
groups mechanism); thanks sem@ for trying out groups/simply/*,
failing to build an image and reporting the problem.
Reported-by: Mikhail Efremov <sem@altlinux.org>

...from "big" to "maxi" as per zerg@'s proposal.

...as it's x86-specific.