- starterkits-20160429

There were two problems:
- the latest pgsql related groups made installation
  impossible (yes, that last minute change);
- hardware testing shows that use/stage2/kms is now
  requisite as xorg-drv-fbdev might just refuse to work
  with what looks like a perfectly good framebuffer...

Do away with them *quick*.

Basically an updated p7.mk.

PostgreSQL has been long neglected way too bad in mkimage-profiles
and the actual builds, let's go and fix that!

Pg 9.5 is the current stable version
while 9.4-1C is the current version
patched to run 1C Enterprise.

This starts a sort of "server merger" by consuming
both samba4 and hyperv subflavours into checkboxes.

Rationale is pretty clear: environment -- including
hypervisors -- is just an install/run-time variable,
and the set of initial services is another one;
no need to maintain a distinct image for each value
when we've done enough of that to know we can merge.

These are based on regular-server-hyperv
(thanks Matt Lewandowsky yet again) turned
into a mere checkbox.

This is a clone of tagged/server+sambaDC pkglist
with added metadata *and* an installer feature
to make things happen at install time; not sure
if regular-server-samba4 is going away any time
soon though as it's useful standalone too.

"Failsafe install" disabling APIC/LAPIC looks somewhat obsolete
by now; the only reasonable part seems to be the attempt to force
VESA videodriver for the installer (should be done within installer
itself though).

Turns out that commit fb4bd77f broke two of the regular builds
by crippling their ability to reboot/poweroff via desktop menu:
http://lists.altlinux.org/pipermail/devel/2016-April/201319.html

Note that kde4 one doesn't need CK indeed.

zerg@ tells that Obsoletes: is flakey in fonts-ttf-droid
so it's better to specify these three packages instead.

- 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.