At the moment, the ability to select the kernel with which to boot is
implemented only for grub (grub-pc, grub-efi, ieee1275boot).
note that renamed STAGE1_KFLAVOUR to STAGE1_KFLAVOURS, as multiple
kernels can now be added.

It is very strange that earlier in STAGE1 added kernel modules from
a variable STAGE1_KMODULES_REGEXP only.
This commit makes the drm feature work properly.

Partially reverts commit e8f63357
which has added an overlooked second `include targets.mk' which
began spamming build.log immediately:

  /usr/share/mkimage/targets.mk:23: warning:
    overriding recipe for target `__profile_internal_rule'
  /usr/share/mkimage/targets.mk:23: warning:
    ignoring old recipe for target `__profile_internal_rule'

*sigh*

This reverts commit 02a5231b.
Upstream mkimage has not yet take patches to support packaging
multiple kernels to ISO image. In order to avoid problems, have
to revert this commit.

This was highly inobvious, and should have been documented
within the very same commit adding the variable!

See-also: https://bugzilla.altlinux.org/30239
See-also: https://bugzilla.altlinux.org/32171

Just missed this change somehow...

See-also: http://git.altlinux.org/people/shaba/packages/?p=startup.git;a=commitdiff;h=2441f9438b7956fabdb353400b9df4abace1d7a0Suggested-by: Anton Midyukov <antohami@altlinux.org>

This is to make building addon images possible;
those carrying packages but lacking any stage2.

The places of the terms *do* affect the sum in apt's case;
start with lowlevel items like SYSTEM_PACKAGES and end with
high-level ones like THE_LISTS to reduce the chance of getting
hit by premature virtual dependency expansion/fixation.

Adapt live and rescue features accordingly.

See-also: https://bugzilla.altlinux.org/show_bug.cgi?id=30806#c5Suggested-by: Leonid Krivoshein <klark@altlinux.org>

af_packet rather belongs to networking stack
than to common module library indeed.
Suggested-by: Alexey Gladkov <legion@altlinux.org>

There's no "arm" entity, what could I mean?..

Another minor facelift:
- s/ALT Linux/ALT/gc (where applicable);
- s/7.0/8.0/g;
- 2017;
- e2k;
- links.

Now that we don't ignore X-Alterator-PackageList
in pkggroup files these few places referencing
group names as list names have broke; bring 'em
in line through this new and shiny function.

stage2 only allows to run certain scripts and install packages, but
sometimes one need just to copy something to stage2 (like stage1 does).

How to use:

put files under ./files directory with the same structure as on
resulting image.

If aufs not available/broken we could try to use overlayfs.
NB: changes below doesn't work without modified make-initrd-propagator!

...regarding THE_* use.

Thanks glebfm@ for noticing that Simply (an m-p-d product)
takes no kernel inside squashfs but relies on livecd-install's
50-restore-kernel.sh hook to copy the kernel from iso9660
and regenerate initrd (which is a must anyways but requires
System.map to be still around).

This saves about 3 Mb in ISO size for a LiveCD using
kernel-image-std-def-4.1.15-alt1.x86_64.rpm.

There's /usr/share/qt5/translations/ now too, handle that.

OTOH we've got some CJK support already, time to split up
those "cleanups" into some target locale set dependent form.

The issue at hand is that:

/etc/tcb/USER/shadow gets USER:auth ownership (OK);
/etc/tcb/USER/shadow- backup file is root:root (broken);
/etc/tcb/USER/shadow.lock file is also root:root (broken).

This is observed for all pseudousers created by package installation
process within working chroots as well as for users created by deflogin
feature; the problem is that e.g. echo USER:PASS | chpasswd will break.

Looks like the cuplrit might be fakeroot/faked.

The flexible KFLAVOURS handling has a downside:
if no packages match the regexp it's silently OK
until too late, and the error is incomprehensible.
Let's fix the latter at least.

It's been found out that live_rw isn't going to work
without ext4 module being available; let's ensure that.

These are aimed to test the modules.d/ and auto-pickup
implementation as well as to present an example.

At least 50-net might change (or just get renamed to avoid
auto-pickup) some day as the "net" feature's meaning is
to provide networking upon bootup and these modules are
only needed within stage1 if we're going to netboot;
and that's quite different thing.

armh-cubox bits are prone to get renamed/generalized too
since e.g. ArmadaXP based server images are going to need
this as well.

These were produced off the single sub.in/stage1/modules
file using this scriptlet to prefix/annotate the names:

  grep '\.ko$' modules \
  | grep -v / \
  | while read m; do \
  	echo "$(find /lib/modules/$(uname -r)/kernel/{drivers,fs} \
		-name "$m" -printf %P $m $(modinfo -d "${m%.ko}" 2>&1)"; \
    done

...with subsequent sorting and manual separation.

This is meant to be the second stage in monolithic modules
file split, so the lists themselves are largely unmolested
otherwise.  The plan is to further split those into prefix-
and module-specific ones.

Add a note clarifying 10-stage2's status, by the way.

What was a static sub.in/stage1/modules (and the only one)
is now features.in/stage2/stage1/modules.d/10-stage2
(basically a compatibility file that might go some day).

It will be auto-picked as its name corresponds to the
NN-SUFFIX pattern specified in stage1 subprofile now
with $(FEATURES) going into default STAGE1_MODLISTS.

stage1's got prepare-modules target collecting
modules file snippets all over stage1/modules.d/
subdirectories within individual features.

stage2 now adds names of all the features going into
a particular image as snippet file suffix list so that
individual features don't have to register themselves
twice (as a feature and as a propagator modules.d
snippet carrier).

This is going to allow both "uncommon" modules getting
included with no problem (sin@ has wanted cifs ones
for quite some time, for example, and some want e.g.
infiniband modules) *and* to reduce the actual list
below the common mark as well (which is the case with
live-privacy image, for one).

And stage1 memory consumption does matter in some cases
as it's highly critical with no chance to use swap yet.

Looks like it's been dumped in along with the rest but not
actually used in {make-initrd-,}propagator; the problem with it
is that snd-dummy.ko matches and pulls a bunch of unrelated
modules where these don't belong (grep -w wouldn't match
snd_dummy.ko though).

These can be found in (semi-)supported branches still:

- loop.ko:
  + 3.0.101-std-def-alt0.M60P.1
  + 3.4.96-led-ws-alt0.M70P.1
- aufs.ko:
  + 2.6.32-el-smp-alt31
  + 3.4.96-led-ws-alt0.M70P.1

ehci_marvell.ko isn't found in contemporary sisyphus/armh
kernels but let's purge it later during archdep rewrite.

NB: libusual.ko has been renamed to usb-libusual.ko as of p6
    (not to be found in p7 anymore), and nls_base.ko was in
    2.6.32 kernels as of p6 but not there in p7; purge these
    somewhere down the road.

This file has been floating around for quite some time,
and some of its contents are pure bit rot by now...

Drop the modules that don't exist as of 3.19.2-un-def-alt1
upon manual diff examination.

It wasn't sdhci_pci.ko back in 2.6.32 actually and it's
sdhci-pci.ko; so grep used by mkmodpack won't pick it up.

This has been missing for *so* long somehow, and adding some 200k
of modules for fast hardware that's widely available by now
looks like a deal.

Added USB Attached SCSI module just in case (or rather for weak
crc_t10dif symbols?).

The former install2-only "bloated binary" purge script
happened to hit stage2 (which is a lot more than just
install2); a kind of safety net has been stuck into it
to guard installable LiveCDs against this particular
cleanup but seems it was not enought for ildar@ who
reported this problem almost three years after it was
introduced.

This change re-places the script back into install2
section; the binaries in question amount for ca. 8 Mb
(except openssl ildar@ asked about); if these are deemed
unneccessary within any other stage2-based subprofiles,
please step up with details.

This function's got its argument order chosen for "aesthetical"
reason of $(2) following $(1) in the macros but the logical order
is exactly the opposite: we care for kernel flavour much more than
for module set (which is dependent upon it).

So while silent dropout of kernel-image if KFLAVOURS is set
but KMODULES is empty could be fixed by testing for $(2) only,
it looks like a good time to fix this discrepancy altogether.

It's been a given that any stage2 is propagator-based
but that's not neccessarily so; the "run X as PID 1"
sort of contest has sparkled interest in some others.

It should state clearly both the positive and negative examples
of rootfs concept use (its name is not consiceenough unfortunately,
and I haven't come up with a better one yet).

Kernel modules come as both *.ko and kernel-modules-*.rpm
and it wasn't clear enough whether to mention "ahci" or "v4l".

There's not much sense in overduplication of documentation
(tends to get stale faster then), still it's not good to
just refer to the code as the PDF/HTML book is less useful
then; maybe drifting towards "recommended" bits with more
"advanced" things being impleentation-defined is better.

It conflicts with r8169.ko inobviously.

The whole mess looks like this:
- r8169.ko doesn't work for all of Realtek 8111/8168/8169 mutations
- r8168.ko works with some of the chips r8169.ko doesn't
- r8168.ko also works with many chips r8169.ko works with
- r8169.ko is provided by kernel-image package (thus default)
- r8168.ko is provided by kernel-modules-r8168 package (optional)
- kernel-modules-r8168 package requires r8168-blacklist package
- r8168-blacklist package is a one-liner that blacklists r8169.ko
- STAGE1_KMODULES wouldn't include r8168 (std-def) or rtl8168 (led-ws)
- sub.in/stage1/modules would mention r8168.ko (m-p-d: r8169.ko)

So a LiveCD built with use/kernel/net might work with RTL8111/8110
just fine when booted live but fail to automatically load the module
when installed onto hard drive; manual modprobe r8169 would work though.
NB: some of the chips (those available to me) would work just fine
both ways -- this has contributed to fixing this *that* late.

Bottom line:

  do not install backup/kludge drivers overriding main ones by default!

Thanks sem@ for providing the crucial hint.

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.

sub/% has moved from lib/distro.mk to lib/sugar.mk
since rootfs introduction with commit g67adab49.