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.

NB: for the feature to work properly the chosen branding
package set should have proper Provides: and Conflicts:,
specifically it must explicitly conflict with the most
lexicographically cool package set around (these days
it's sisyphus-server-light).

As duly noted by glebfm@, branding issues need more attention
by now since only stage1/install2 got some of it so far in this
regard.  Hence the dedicated feature comes to the rescue
(well no, it doesn't actually mess with rescue!).

From now on, subprofiles can include the lib/*.mk
brought in by features just like image.in/ long did.

Thanks glebfm@ yet again :)

- simply better (tm)

There will be two types of Simply: DVD and Live versions.

Following m-p-d, a more involved default output directory
structure is feasible now:

  ~/out/name/date/name-date-arch.type

instead of plain

  ~/out/name-date-arch.type

This particular behaviour can be achieved by passing
SORTDIR='$(IMAGE_NAME)/$(DATE)'; note the single quotes.

Reports are also saved in this resulting structure
albeit the place is still highly debatable.

REPORT_PATH comes from a makefile;
let's use corresponding notation.

Trying to extract reports for a failed build is a bad idea.

That's what command-line variables serve for
(without causing a combinatorial explosion) :)