Images building from the generated profile will have mkimage-profiles
commit information.

There is no point in duplicating conditions.

mki-copy-grubaa64boot more not needed. In addition, it did not
support the config in boot/grub instead of EFI/BOOT.
Needed mkimage >= 0.2.38-alt1

This one can be used to override the default content
of .disk/info file (used by propagator but can find
some other uses within installer as well); the reason
being that ISO9660's Volume ID is up to 32 characters
and a file lacks that particular limitation.

There's an ISO9660 COPY tag for license info file;
make use of it, factoring use/docs/license out
while at that.

One of the goals was to make it hold the reference
to reference to GPL in regular builds and starterkits
;-)

A bunch of duplicated variable names for mkimage,
just short-circuit those to the already available
(and hopefully filled in) BOOT_* ones.

Every .iso was assumed to be bootable since the very beginning[*],
and isoboot images were deemed to be x86 isolinux ones; this didn't
change with basic ppc/armh support as I never ran into hardware
that would _boot_ those ISOs, not only run the code, and it was
only e2k isodata project that finally forced this refactoring.

It's still not perfect: pack and syslinux features still end up
somewhat interwoven, and too much places care for architecture
the image is being built for (instead of archdep features tossing
their appropriate bits and pieces in).

Should help:
- any-arch regarding isodata images;
- {x86,aarch64}/efi by decoupling isoboot and isolinux;
- ppc{,64} as introducing yaboot support will be easier now;
- mipsel{,64} too, hopefully.

* I knew of school addon images baked with mkimage-profiles-desktop
  but postponed and then neglected the whole problem for years...

It needs (and has) no isolinux in the first place;
this is also the situation with most or all non-x86
arches, the code should probably reflect that.

This is a fix to previous failures of
ve/vm + use/repo/main build attempts
(in fact, any non-distro/ targets).

SUBDIRS were just optimized away...

...just in case (make doesn't guarantee that it's left-to-right
for normal-prerequisites so make them order-only-prerequisites).

It used to be a hasty static string; something like
"ALT Linux regular-e17/x86_64" seems more relevant.

rootfs presented a special case when there is no resulting
directory at all as it gets merged with the target subprofile
by design.

Still those features adding only rootfs scripts need to depend
on it but this resulted in an attempt to process a missing subdir.

This is brought back to sanity now.

Its support was dropped in mkimage some time ago
since xorriso semantics changed quite considerably
and the tweak that was done here is now performed
out-of-box thus no longer needed.

The nice and pleasant effect of hitting this barrier
is build process break at (almost) the very end of it.

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.

There was some extra duplication, just clean it up.

Yes, mkimage-profiles is now able to build VM disk images.
So far the support is pretty basic:

- a single hard drive image with a single partition/FS
- only stock root password is configurable
- LILO is hardwired as a bootloader

The resulting images tend to boot under qemu/kvm though.

Please see doc/vm.txt for the warning regarding additional
privileges and setup required.  This was started back in
February but I still hoped to avoid sudo/privileged helper
(and libguestfs is almost as undistributable as can be)...

Thanks:

- http://blog.quinthar.com/2008/07/building-1gb-bootable-qemu-image-using.html
- Alexey Morarash who reworked that as https://github.com/tuxofil/linsygen
- led@, legion@, vitty@, aen@ for providing advice and inspiration

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.

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

As was noted by Alexey Shabalin in libosinfo context,
current ALT Linux images tend to lack ISO9660 metadata
-- which they did have back in the day of Master 2.4.

Please note that the data collection occurs this way
due to mkimage's config.mk resetting the values to be
empty; this was worked around by using another config
file, $(BUILDDIR)lib/iso.mk, and including it later
but that would require a separate target with per-target
CONFIG variable which isn't elegant at all given the need
to actually build up the metadata set.

So the variables were changed (to be more readable anyways)
and then proxied back to BOOT_*.  This might be cleaned up
some day after the inclusion order is tweaked or mkimage
defaults get set-if-unset-yet (?=).

mkisofs can use hints on file disposition; this needs some
support on mkimage side but that's pretty trivial (hope to
see it in 0.2.2+).

As too many things started duplicating between distros proper
and (e.g. corresponding) LiveCDs, it became apparent that a class
of entities which end up working for THE_USER (not a sysadmin,
and not a developer, just a Linux user) is in need.

So THE_KMODULES will power installed basesystem and live image,
while THE_PACKAGES, THE_LISTS and THE_GROUPS will participate
in building those.

Actually there's an added duplication in the form of the
test that was previously missing in pkg.in/lists/Makefile
-- that has to be done properly when it's clear how.

This fully omits pkg/lists/.base generation in environments
that won't make use of it.

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

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

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)

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)

install2 cleanups:

- functionally indifferent ones: particularly, install2/*/98system's
  "mkdir -p /image" was superfluous as it was done by that time already
  by sub.in/stage2/image-scripts.d/00stage1

- taken apart, prepared for tags: so far it's a mostly moot change
  since the installer cleanup scripts themselves are mostly the same as
  preceding 90cleanup was (with some additions corresponding to recent
  kernel development); it's still unclear what the mechanism for
  configuring the cleanups in effect will be, either directory/package
  regex lists or tagged scripts excluded from execution by yet another tag

fixes:

- image.in/Makefile: fix metadata related test; the actual test was
  assuming that stage1 kernel means installer, which is not the case
  since generic stage2 introduction; oh well

- 85cleanup-lowmem: a "_" too much was the culprit in destroying the
  needed translations along with those deemed superfluous; thanks go to
  Oleg Ivanov and Lenar Shakirov for finding the bug and proposing the
  fix altogether

additions:

- features.in/Makefile: reworked help target; it was rather inaccessible
  due to BUILDDIR normally undefined at the time of direct make
  invocation, and BUILDDIR is normally defined during normal builds
  anyways so let's try it this way.

- README++

daydreams:

- 01-genbasedir: we should drop bzip2 compressed pkglists some day
  but see genbasedir and apt-cdrom first, 90-pkg.sh (alterator-pkg)
  will fail miserably otherwise

It was clear that "common" isn't very apt for packages that
will get *everywhere*, and became apparent when the need for
a "base+live packages" variable arrived with powerbutton feature.

So:
- the former COMMON_PACKAGES are now SYSTEM_PACKAGES;
- COMMON_PACKAGES act as "BASE+LIVE_PACKAGES".

Note that SYSTEM_PACKAGES also got factored out from stage2 based
features into stage2 subprofile itself; cleanups were due as well.

MAIN_GROUPS should align better along with MAIN_PACKAGES
and MAIN_LISTS (even if MAIN_ prefix might be suboptimal
given that these packages are essentially extras within
the particular image).

- introduced generic stage2 subprofile (non-standalone)
- ported installer and rescue over to stage2/{install2,rescue}
- initial stage2/live (needs more work for sure)
- use make-initrd-propagator
- updated and somewhat extended doc/

NB: mind #26133, #26134

s,INSTALLER_KFLAVOUR,STAGE1_KFLAVOUR,g
s,INSTALLER_KMODULES,STAGE1_KMODULES,g

install2 isn't the only livecd around;
so far all of these share the same kernel
in m-p-d, and we'd rather need two+ kernels
with dual-arch media or so; let's not complicate
things too much at this point

make CLEAN=1 will prune workdirs after packing their results,
so disk (or preferably tmpfs) usage will be lower

In particular:
- .base is now generated from pieces (see image.in/Makefile)
- s/DISTROS/IMAGES/g; s/CONFIGS/DISTROS/g (for clarity)
- s/DISK_LISTS/MAIN_LISTS/g ("disk" was early m-p-d legacy)
- introduced BASE_PACKAGES to complement BASE_LISTS
- minor tweaks to Makefile (ARCH and DATE moved elsewhere)
- libdistro.mk: dropped overlooked IMAGE_INIT_LIST copy
- clean.mk: silly cleanup

This looks a bit weird (two subprofiles become a bit more
tightly coupled) but in fact install2 does depend on stage1,
and if stage1 doesn't create squashcfg.mk then install2 is
just fine with defaults (provided they fit the installer kernel
used).  A proper mkimage test infrastructure might be handy though.

Also there:
- 01-initfs: partial cleanup (bootsplash is obsolete anyways)
- regarding 03-test-kernel's errorlevel test:
  if 0, 1 and 2 need to be distinguished, "!" MUST NOT be used
  as it negates so that 0 becomes 1 and the rest becomes 0