Why would anyone try to remove apt when it's needed
for package dependency tracking for the installation,
it only takes a less cursory look at the build.log
to figure out it didn't actually happen anyways...

An initial draft of it was done half a year ago but several tricky
thingies had kept the code from showing up as it was rather brittle
and incomplete.

This implementation involves quite a few changes all over the place
but finally works good enough for live and installer images.

Please pay attention to the versions of these packages:
- installer-feature-setup-plymouth (0.3.2-alt1+)
- branding-altlinux-sisyphus (20110706-alt2+ if used)
- plymouth (0.8.3-alt20.git20110406+)

See also:
- http://www.altlinux.org/Branding
- http://www.altlinux.org/Plymouth

- minor bugfixes

The more or less basic desktop appeared to lack
base locale support (starting with glibc-locales).

It somehow managed to evade me that $(TMP) might be uninitialized;
definitely should be checked before stuffing into sed substitution
command.

NB: this could be done in pure make but my take was less readable.

Thanks shadowsbrother/gmail for hitting and reporting this.

legion@ implemented skipping depmod call, and that's several more
seconds for most of the images; let's shave these off if possible.

- docs updates

It might be spottable but not immediately obvious that a feature
lives entirely in features.in/FEATURE and every target it provides
is described in the corresponding config.mk; thanks dkr@ for asking.

It wasn't exactly obvious that the actual image build
isn't started with CHECK=1.

It appears that while splitting off main.mk we've lost
the ability to pass e.g. ARCHES via custom configuration;
thanks dkr@ for spotting this.

Whoops, forgot to feed placeholders for git to grok
the empty directories that are needed later...

It wasn't articulated clearly enough that features are strictly
incremental (while variables can be overridden).

lightdm-1.1+ handling had to be corrected
regarding the separate greeters.

virtualbox-addition modules need drm (see also #27344).

`make check' is a bit more convenient than relying on my head...

Shame on me, these shouldn't get forgotten in the first place.

- build helpers refactored
- initial frontend support

udisks seem to pass up META_VOL_ID;
let's make it a bit more informative.

nouveau just didn't work out on a GF7100 at hand
(while nvidia did fine) as well as on a MX440.

Need more real hardware testing though.

Just like livecd-install, graphical installer KMS support
looks better as an optional part of install2 feature.

Of course it's optional only if the release manager is fine
with VESA drivers and not KMS-requiring intel/radeon/nouveau;
thanks led@ for a confirmation just in case.

After having added metadata dependency livecd-install
started to look more like a feature than like an intermediate
distribution target; so things were shuffled a bit that way.

This further refines the modular build by making
metadata being a clearly separated feature rather
than having to rely on runtime tests, and also by
moving the code which cares for kernel bits of base
installation (.base list) in a feature of its own.

There's more to it but let's get the ball rolling first.

- branding feature

The initial work covered live images but missed an installer bit
(thus notes and slideshow were missing in install2) while forgetting
to put branding packages into base list (thus kindly making these
available for *manual* installation sometime after, ouch).

E17 has a lil' bit too thorough setup sequence
for a LiveCD but hey it's worth it anyways :)

It's actually convenient to test new software (moreso stacks)
in a known clean isolated environment ;-)

Thanks "asd" at opennet for the motivation to do it all:
http://www.opennet.ru/openforum/vsluhforumID3/84402.html#109

It's a bit simpler to choose "boot from hdd"
than to eject a disk/ISO.

No need for the specific apt-conf either.

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

It was done in other stage2 mods already.

It's hard to tell a successful build from a failed one
if downstream hides the exit code; it's useless to continue
a `for' loop if a pipe shoves that to a subshell; well it seems
that a bashism is worth a thousand quirks with extra fds here.
Minor regexp enhancements are also due.

reports.mk made a bit more resilient/prudent either.

No need for .reports/ in toplevel directory even after build failure,
and a few more hasty hacking fixups are also due, shame on me.