It's official now.

Actually this is the proper rewrite that was looming ever since
tgz support was introduced: there are multiple archive formats
supported by mkimage, and there are multiple compression methods
available as well.

So the bullet got bitten yet again along with the "goal parser"
which should be more straightforward by now.

Thanks dkr@ and mithraen@ for the inspiration of this evening.

Partially reverts "Makefile: presume a distro by default" commit:
plain `make' should better help the user to decide the target
rather than rush to build them all upon her.

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

As noted by imz@ in #26608, a LiveCD is the more preferred
boot target to a local drive usually (just as was discussed
and implemented for ALT Linux 4.0 IIRC).

It was actually trivial given that the script was already
maintained as a package by enp@ and msp@; its usage requires
one to manually partition the target disk and optionally
mkswap in advance.

This tweak follows zerg@'s question whether it's possible
to employ i-f-cpufreq-stage3 (which pulls in cpufreq-simple too
but also tweaks the default governor for AMD CPUs as recommended
by kernel folks); see also this discussion:
http://lists.altlinux.org/pipermail/community/2011-November/thread.html#673459

- add_feature for autoregistration (simple but invasive)
- added features: isomd5sum, repo, systemd
- changed features: powerbutton -> power

When ve/ support was introduced, a simple "make icewm.iso"
had to turn into the more elaborate "make distro/icewm.iso".
This latter one involves several keystrokes more, which is
not even (environ)mentally friendly.

This was supposed to get fixed somewhere down the road with
a fallback but the elegance of IMAGE_* setup waterfall barred
me from tweaking IMAGE_TARGET at once (and the downstream fixup
would imply re-tweaking the consequent variables as well which
is blatantly anti-mkimage-profilic being a brute fork).

OTOH testing for a "directory" part of the goal is going to
either deadlock on IMAGE_CLASS or duplicate its assignment.

So now when I've had enough typing an extra "distro/",
I'm going to just bite the bullet and tweak IMAGE_TARGET
with a test duplicating IMAGE_CLASS assignment indeed
(testing for e.g. "/" results in a different test,
which would be worse yet).

Please suggest a more elegant solution if you invent one!

As was (quite reasonably) asked by someone and me too,
why should a successful build yield a *red* line
(a grep's default)?

So now it's new and improved, 25% free and so forth:
with a successful build you get a green line, while
errors from a broke one result in red ones.

Clinically tested in both b/w and w/b colour schemes;
in case you're not satisfied, please return original
ANSI_OK and ANSI_FAIL values to the colour dealer
and pass your favourite ones instead.

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 features might get copy-pasted (or even copied-and-pruned)
when initialized; there's an unneccessary duplication of the
function name in the line adding it to FEATURES list, thus
prone to being forgotten and causing some havoc later on.

It was wrong in the first place but tackling this with some
double-colon rules ran into terminality issues, and further
tortures were considered unneccessary.

The current solution isn't perfect (no completely transparent
function name registration upon corresponding target being called)
but at least it is an improvement...

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

It appears that features.in/Makefile functioned a bit
differently by now than was described back then: after
loops and pushds got rearranged for robustness, it stopped
to pick up a cleanup feature tagged script.

That particular script is now better de-tagged and simply
placed as a script to be merged into install2 subprofile.

The tagged scripts still require a bit more comprehension
to understand the use cases (e.g., do we need per-subprofile
tagged script subdirs or just a toplevel one should be looked
at, with script names telling where to put them).

README used to mix up subprofiles and features; fixed.

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.

server-base += openssh-slients
xorg += xorg-drv-wizardpen

This is a base for "media check" to become available:
using this feature will implant a checksum into the image
so that it can be verified during install.

Also added a test/demo distro/live-isomd5sum target.
For real distros an alterator module is probably due.

This might be needed to install onto an SD card in a "native"
(non-USB-mediated) SD/MMC cardreader; thanks Vladimir Karpinsky
and gns@ for going over it for liveflash.eeepc case.

It is a current convention to prefer clearly phony targets
(see the wiki page) so let's follow it here too.

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.

- mkimage version required/checked

There's a recommended version (0.2.0+ currently) and also
the minimal version, 0.1.7, which received the important fixes.
It was proposed by nice antique@ folks IIRC.

Unfortunately the "suboptimal version" warning is pretty modest,
and "minimal version" error will be apparent with DEBUG enabled;
still the latter will terminate the downstream build and leave
a clear message in build.log at any rate.

- CLEAN by default unless DEBUG

CLEAN is so useful and fiddling with .work chroots does
demand knowledge (hsh-shell is handy btw); so unless we
really get our hands dirty, let's spare ours preciouss
tmpfss.

- include %mpdir/ itself as well

- enhancements to logging
- NICE variable: employ nice(1) and ionice(1) if available
- features.in/syslinux: banner tweaked to include target name
- features.in/live: set up unicode locale/consolefont

- toplevel README received some long-needed refactoring
  + lowlevel detail moved, well, to lowlevel READMEs
- reflected more thoroughly that m-p is not about distros anymore
- dropped features.in/00example/README.en: it's already out-of-date
  a bit, and there's no perceived need in thorough English docs so far
- wiki article got split into parts and somewhat rewritten, links updated
- mv doc/{CodingStyle,style.txt}

This only deals with console output (a text livecd doesn't ask
the user regarding the preferred language so far).

Refer to these discussions if needed:
https://bugzilla.altlinux.org/show_bug.cgi?id=25225
https://lists.altlinux.org/pipermail/devel-conf/2005-August/001785.html

The bigger goal was being able to set up build in a way
that would allow for images (with configs and logs) be
deposited in per-IMAGE_NAME subdirectories of IMAGEDIR;
that's not done yet but a part of it is ready.

NB: in BUILDDIR, symlinking the just-built image is now
replaced with symlinking the IMAGEDIR since its location
is then predictable thus .gitignore-able for further work
on a generated profile, and more documentable as well.
It's not a hard change though, if you miss the image link
just drop me a note (or a commit).

Essentially some more polishing:
- image path extracted from downstream build log;
- extended error/warning regexp a bit so those with
  color grep options get even prettier output.

Notes:
- "1024" a magic number (briefly explained when introduced)
  moved to a sort of variable;
- "100 lines" for tail(1) is a rule-of-thumb taking into account
  typical amount of hasher/mkimage exhaust given GLOBAL_VERBOSE.

Preferences might be somewhat interesting too: while the official
ones shouldn't influence the build result at all, there's no whitelist
so all kinds of weirdness can be stuffed into local config in principle.
That should be diagnosable at least.

This one regulates the build wrapper: if the value is non-empty
then nice(1) and ionice(1) will be attempted so that the build
behaves better in regard to other tasks running on the system.

A few doc/variables.txt updates along the way.

Back then I didn't come up with anything smarter than
"mkimage-profiles 2.0" (with my tongue in a cheek),
but as m-p has grown up to 0.4 it's time to fix this.

When done properly, all of the string should be brandable
(with some sane default value inheriting from image name),
but let's do it at least bit by bit.

Thanks torabora@ for yet again seemingly obvious feature request
which strangely managed to evade implementation before.

On an afterthought, mass builds would suggest too much coffee
instead of a progress indicator -- so implemented the latter.

NB: the actual downstream-make-calling rule would expand the "naive"
$(shell date) too early: the rule is evaluated before starting its
execution, and as it's the time consuming one the shell evaluation
was in need, not make's.  The result is less generally available
(needs to be double quoted and won't work inside e.g. awk programs)
but way more precise.

The seemingly obvious feature was proposed by torabora@.
APTCONF complicates things a bit of course...
(and was slightly kludgy btw; fixed)

Also added to the live-builder ISO which is now self-hosted
(sans full repo): one can build an image capable of rebuilding
itself (which is not that useful) and of building other goodies
on some temporarily unused RAM-filled hardware (which is the goal).