It was a mistake to add branding package to the initialized chroot. There
were no problems until the package had dependencies. Now, when most branding
has a dependence on alt-os-release, chroot initialization broke.
See also ALT bug 41570.
Branding needed to be added to PACKAGES_REQUIRED_INITROOT so that it is
installed with basesystem.

...otherwise:

$ make QUIET=1 REPORT=1 THE_APT_CONF=branch BRANDING=alt-starterkit ...
/bin/sh: line 5: [: too many arguments
/bin/sh: line 28: [: too many arguments

This reverts commit 366cb49d.
.gitignore is needed for packaging empty catalogs to the profile archive.

Requires support at mkimage.

See-also: https://bugzilla.altlinux.org/show_bug.cgi?id=40148

Previously, you had to specify two parameters MKIMAGE_PREFIX and
GLOBAL_PREFIX with the same value - the path to mkimage. And this
behavior has not been documented. The GLOBAL_PREFIX variable is
defined in mkimage in config.mk and rules.mk.

This is necessary to prevent accidental hit of another branding.
Usually the problem is solved by setting up pkgpriorities  in apt settings.
But this is inconvenient when you need to make building often with others
branding.

find's argument order is a bit different indeed.

Don't go crazy if Dir::Etc::sourceparts/d
gives something strange (e.g., /).

Should be ALT instead of ALT Linux now following
the update of the branding itself; ALT Linux Team
stays ALT Linux Team of course.

This is an initial implementation of architecture dependent
contents handling for package lists more or less in the vein
of mkimage-profiles-desktop's one *but* using suffix part to
filter words in or out *not* prefix part to replace it with
a comment marker (thus filtering out lines).

The syntax should be pretty obvious:

  a b@i586 c@x86_64

will get "a b" given ARCH=i586 and "a c" given ARCH=x86_64;
please see doc/archdep.txt for a more elaborate description
and a conversion script.

This one reduces the amount of output that's only
interesting when one is actually watching the console
during builds (at least the early stage) -- these tend
to look boilerplate and be useless when inspecting the
output of a large batch build like [[regular]] one.

Just spotted that .disk/profile.tgz would hold
distcfg.mk with pre-expanded $(HOME) from build
host which is both info leak (user account that
was used to build the particular image) and just
wrong given that the in-image profile archive was
conceived as a means to pass that part of build
environment over instead of tying it to vendor.

Morale: premature optimization is premature.

It happens when there are no separate arch/noarch subrepositories
but everything is dumped into a single directory like in installer
or live-builder environment (at least as of today).

Now this is ugly: instead of commoditizing the repetitive code
the result ended up working differently by creating several
repositories for the target subdirs instead of the single one
for the generated subprofile as a whole.

This results in .disk/profile.tgz being basically useless
in every image since c4311108.

It appears that manually specified IMAGEDIR, e.g. by adding

  IMAGEDIR = ~/out/$(shell date +%Y%m%d)

to ~/.mkimage/profiles.mk, might be problematic due to
missing globbing.  Let's make sure the paths are globbed
and directories are created -- since make's wildcard()
returns an empty string when there's nothing there [yet].

ildar@ noted that the test involving whitespace is too
quirky for some quirky enough cases like

  rpm-dir file:/var/cache/apt/archives . x86_64

-- let's introduce word boundaries there.

This isn't ready for general consumption (just as centos one)
but the notion of REPO is floating around along with apt-conf
thoughts, and it might still be useful to someone poking around
conf.d/test.mk.

Request hasher-pkg-init.spec from mike@ or led@ if interested;
the experiments were carried out using openSUSE 11.4 repository
and slightly patched hasher (cpio blacklist for devices).

That sub/stage2/install2 was somewhat clumsy actually as it looked
like a hierarchical thing while being a substitution thing:
generic stage2 would get put in place renamed as install2.

This could only get worse with hierarchical features which have
already been both requested and considered for quite a time,
and "stage2 at install2" reads much more naturally.

There were heaps of "if type -t git" there already;
it wasn't an unintentional mishap but rather a moderate
copy-paste to get the use cases, and now these seem to
have essentially settled.

So time to scrap some dups.

NB: the scripts in the generated profile can't rely on
the contents of the metaprofile (these need to be able
to work in standalone case either), so a bit of crap
still lurks there.

mkimage and hasher can make use of qemu to run
non-native binaries while working on the chroots;
thanks kas@, manowar@ and sbolshakov@ for implementing
this functionality as well as providing nice examples
through mkimage-profiles-arm and mkimage-profile-armrootfs.

This required the architecture check to be added since baking
a tarball with "arm" as its specified arch and x86_64 inside
isn't particularly good thing to let slip through; however
the implementation is quite fragile, bugreports and patches
are seriously welcome.

NB: APTCONF evaluation order between lazy make and nimble shell
turned out to be quite a delicate issue in this particular case.

Allow to put the log files and reports in a custom directory instead
of IMIGEDIR.

This one extracts the exact time-ordered list of script hooks
run while building the image.

Some commons refactoring is also due.

bin/ prefix tried to become a permatemp(tm).  No way.

127 is also returned by dot(1), and we're toasted
if unable to create $(BUILDDIR).

The purpose is being able to examine particular target interdependency
graph for a given image having been configured to avoid convoluted
dependencies (loops in particular).

The implementation is based on SHELL hook hint by John Graham-Cumming:
http://cmcrossroads.com/ask-mr-make/6535-tracing-rule-execution-in-gnu-make

As was found out by Vladimir Karpinsky (thanks for patience!),
the autochosen directory might still have too restrictive mount
options -- nodev and/or noexec.  Hopefully the diags are a bit
better and faster by now.

The former toplevel Makefile is now toplevel main.mk;
this change allows for multi-target, multi-arch processing
in the current toplevel Makefile.

As the "build" symlink semantics change quite considerably
when one is doing bulk builds (several pruned builddirs might
be useful for comparison), BUILDDIR is now much more likely
to be recreated: the cases when it will persist are when it's
either a single-image build or when the prefix hasn't changed.

There are some more or less subtle bugfixes and enhancements
all over the map as well.

Done within 20111230..20120102 timeframe, actually...

First, let's not do rsync --delete on an unverified target dir
again: the lesson was learned during a subway hacking session
and I must say that SSDs are frightening fast (even if it was
more than a second to realize what happens and terminate the
extermination before it got /home, thanks xterm).

Second, let's use a variable for common name and make's own
realpath function instead of external binary.

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.

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)

If you make distro/live-builder.iso, the result is an image
containing almost everything (short of actual full enough
repository) to rebuild itself.  It will attempt to configure
eth0 with DHCP and reach http://ftp.altlinux.org for packages.

RAM requirements start with 2Gb, self-build is accomplished
on a 4Gb host with "make CLEAN=1 distro/live-builder.iso".

Packages required for "make distro/syslinux.iso" get included.

(some due fixups all over the place too)

...and create a symlink to a just-built image from builddir too.

This is quite a large-scale change since mkimage-profiles got used to
baking distributions over the last year, and virtual environments are
quite different, so e.g. image.in/Makefile had to be split in two with
the main part of it moved into features.in/iso/lib/.

Short overview:

- features.in/Makefile: lib/ support
  (supporting VE images requires dynamic modifications
  to image.in/Makefile before starting the build;
  the most natural way to achieve that seems to use
  features mechanism along with makefile include dir)

- packaging format related part moved into features.in/pack
  (should be better prepared for diversity either)
- features.in/iso renamed to features.in/build-distro
- features.in/ve  renamed to features.in/build-ve
  + NB: these could not be merged as e.g. features.in/build
    due to completely different script hooks

- lib/image.mk renamed to lib/build.mk
- image, config, log postprocessing moved downstream
- added a sort of a topping in the form of lib/sugar.mk
- assorted style fixups (like ifeq usage)

- clean.mk: reliability fix (the problem was observed by Oleg Ivanov
  and me too but finally it did get the attention quantum)

- reviewed, updated and extended docs
  + QUICKSTART: should be[come] a step-by-step guide
    (thanks Leo-sp50 for prodiving feedback)

This was done while debugging GLOBAL_CLEANUP_PACKAGES
getting doubled... as it got no hard initial value but
rather was always added to, it appeared that at least
stage2/Makefile would obtain a once-initialized value
from upstream and double it while including distcfg.mk
itself.

It's way less hassle to just proxy the value once.