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.

ieee1275boot bootloader support was added in mkimage 0.2.27.

Some images (i.e. docker and systemd-bare) require apt
but do not require etcnet.

Just stumbled into that and (falsely) blamed vseleznv@! :(

Some images will now be better off with GRUB;
rework ve/.bare while at that (splitting the
image targets appropriately).

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

find's argument order is a bit different indeed.

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

There's no qemu there so far, and there's no need
to fiddle with setarch either.

NB: part of this commit erroneously went into
    1c777c8a
    quite some time ago, sorry about the mess.

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.

These two should improve rescue image usability
for system provisioning.

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 performs distclean upon successful image build.
Suggested-by: Andrey Cherepanov <cas@altlinux.org>

s/ALT Linux/ALT/gc

A classic brown paper bag bug: this was typed in a hospital
and that commit was a sick one indeed, the condition should
have been the opposite.
Reported-by: Ildar Mulyukov <ildar@altlinux.org>
Closes: #31982

...as it's x86-specific.

Either /etc/hasher-priv/system or /etc/hasher-priv/user.d/$USER
must contain at least "allowed_mountpoints=/proc" for mkimage
to work for mkimage-profiles; thanks Daniil Golovanov for
providing feedback indicating the lack of the corresponding
checks.

Spotted when working on http://linuxpiter.ru slides.

It was superfluous in the first place indeed,
and new grep(1) considers the option deprecated.

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.

The __frontend variable was introduced to address the needs
of alterator-mkimage module: list the images available in
one column, purge the builddir.

Looks like we should consider other cases with redirected
stdout (cron builds, piped calls, etc) like fundamentally
non-interactive and behave the same.

So commit 3a8af6b5's
description is wrong now; the current cleanup rules are:

- if CLEAN=0 or DEBUG>1, don't do it;
- if CHECK or REPORT is set, don't do it;
- otherwise if at least one of the following conditions is true:
  + there's more than one target being built in a row;
  + stdout was redirected (cronjob, alterator-mkimage...);
  + metaprofile directory is read-only
  ...then do a distclean.

If that doesn't suit your needs, describe the particular
situation please.

Thanks cas@ for wondering aloud whether greppable output
is unsupported with `make help'.

Yes these bits are related to distro/ prefixed images
still the overgeneralization in distro.mk didn't pay off
but rather hid a bug with the only boot/isolinux in use
having no dependency on use/syslinux (which is required).

Maybe this will get revisited when we have other kinds
of bootable images with other bootloaders (vm/ ones care
for themselves as of today).

There's a particular problem with lazy evaluation
in case of BOOT_LANG: mkimage uses internal variable,
BOOT_LANG = $(GLOBAL_BOOT_LANG) (note the lack of
immediate assignment there), and if we set up

  export GLOBAL_BOOT_LANG = $(BOOT_LANG)

in the same namespace we end up with recursively
defined pair of variables; a ":=" in either place
would save the day _but_ it's not there in m-p due to
accumulator variables, e.g. USERS, which are defined
and exported by a corresponding feature and then get
populated *after* having been declared for export,
_and_ it's not in mkimage as of 0.2.16 for some reason
that might even be good (I don't know yet).

set() is a function of two variables but the and()
check for *both* is incorrect as one might need to
override a previously set variable with empty string;
this has manifested itself with a case like this:

  @$(call set,ROOTPW_EMPTY,1)
  # ...
  @$(call set,ROOTPW_EMPTY,)

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.

This change is done to reduce ambiguity in some cases;
the previous intention has been to ease navigation when
staying in a particular directory, now it's been changed
in favour of convenient toplevel `git grep' in fact.

Both variants have their pros and cons, I just find myself
leaning to this one by now hence the commit.  Feel free to
provide constructive criticism :)

Some path-related bitrot has also been fixed while at that.

The behaviour that sort of settled didn't actually follow
the principle of the least surprise when one really wanted
to have BUILDDIR available for inspection; DEBUG=2 would be
effective to achieve that but CLEAN=0 would not.

Thanks led@ for spotting and reporting this.

lib/*.mk aren't going to be parsed for build targets
in the near future; and the early placement of those
targets was superseded by a dedicated configuration
snippet directory so just move these bits there.

I've finally moved away from LC_MESSAGES=C on my main
development system half a year ago and finally spotted
that a grep for "Stop\.$" stopped to yield anything now.

This one is finally there and should help reduce the
systemd-induced mess in package lists and specifications.

This subprofile is akin to THE_* variables family: the configuration
bits and script hooks sitting there influence whatever chroot is
declared to be the user facing one in the end, whether it comes
from vm image or live subprofile.

The services feature ought to be a changeset of its own which would
be based on rootfs and become the base for ve/vm changes but I chose
to just do it atomically; some pre-existing duplicates are pruned now.

These have been proofread somewhat to correspond
to the current state of affairs; a missing one
was added for fonts feature.

This one is a part of a larger rewrite to move away from
distro-centric build-up to configuration-centric one with
the particular packaging being of secondary importance
compared to actual functionality.

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.