Wonder how it managed to evade this list before...

xfdashboard is a GNOME Shell-like window switching interface
and application runner; xfce4-whiskermenu-plugin is another
(KDE-like) menu search facility; thanks sem@ for suggestions.

It's a pretty solid PDF viewer;
pcmanfm-qt integration to be sorted out later.

Just for the fun of it!

- (sysv)init: exclude systemd explicitly

It's not as bare as it should be due to interactivesystem
being slightly more than it ought to.

The issue at hand is that interactivesystem pulls in
network-config-subsystem and that one has several providers
by now, systemd-networkd being one of them since recently
(and pulling in systemd).

Just the same problem as with systemd-journal; both might be
fixed by reworking mkimage to allow for different package name
resolution modes:

- "slap everything together and resolve with one-shot"
  to handle conflictless situations (most of those);
- "process multiple transactions to allow for conflicts"
  thus making it possible to include e.g. a few MTAs into
  the provided package base.

Ensure that systemd is outside by explicitly telling so
in the pkglist.

...and factored out common gtk subtarget removing qt
(it's not exactly helpful to drop a library your browser
is based on in qupzilla case).

This one isn't in menus even but is quite nice for semi-kiosks
it seems; well worth further attention, and let it lurk around
just in case.

E19 would ask the user if they want to shut down
when facing power button event; it won't get a chance
though as the system will hurl down immediately as per
acpid-events-power package provided configuration.

- kpackages() argswap

It has arrived to sisyphus last week silently,
thanks aris@ (#30253).

-mini image should be flash-friendly to be more useful,
and -flash bugtraq kitchen sink could use/efi as well.

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

This should avoid ruining principle of the least surprise
with ROOTPW_EMPTY=0 or ROOTPW_EMPTY=n actually *enabling*
empty root password; overriding an already set "1" with "0"
becomes possible either.

That is, move use/efi/signed from basic -mini image
to the complete one; make the former isohybrid but
otherwise keep it small.

These started out with the now-classic vi and emacs ones,
elinks has been the next step, and bash helps debugging.

This one has been inspired by these guys:

  http://www.informatimago.com/linux/emacs-on-user-mode-linux.html
  https://raymii.org/s/blog/Vim_as_PID_1_Boot_to_Vim.html

It's aimed at building images running their main userspace
piece instead of ramdisk's init, that means PID=1, UID=0.

Mostly fun of course but it suddenly became interesting with
kernel IP autoconfiguration and e.g. elinks running this way
(NB: requires patched make-initrd 0.8.8 at the moment to get
resolver configured).

And startup times are way better than sysvinit and systemd combined!

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.

stage2 has been thinking it's synonymous with propagator
and used to usurp kernel's belongings either; carefully
tear scripts apart so that kernel feature makes sure
initrd gets generated, and stage2 (which is still all
about propagator) cares for its bits.

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.

xorg-drv-vmware is desirable for guests with X11
but undesirable for text-only ones; let's provide
this knob at least but ideal m-p would figure out
that an image with use/x11 and use/vmguest/vmware
should receive this intersection either.

- regular fixes

IOW URW EOL

This aims to work around URW fonts deficiencies combined
with the relatively high position of their standard ones
in default /etc/fonts/conf.avail/60-alt-post-user.conf;
see also #30293, #30294.

This has missed 20140912 starterkits unfortunately,
nightly builds excluding installers didn't catch it
and beta testing hasn't uncovered this either.

It's not EFI-bootable due to the extra size penalty
with current build/boot technology, but it's also
not ISO-hybrid as most images are made hybrid by
making them EFI-capable as well since the processes
are related.

Thanks dango at the forum for asking:
http://forum.altlinux.org/index.php/topic,33094.msg236808.html#msg236808

Makes no sense without ahttpd anyways;
thanks lewellyn@freenode again.

Disable bridge service as well
(gotta figure out what pulls it in).

- starterkits alpha

Borders with archive+extra but that one contains standalone tools
and this is a FUSE-based one -- with more of those included in this
particular pkglist already; if we decide that it's a worthy addition
to any image requesting a bunch of archiving tools then it might move.

It's useless as of right now:
- menu file and udisks2 dependency are missing
- udisks2 itself lacks an initscript

Let's note these deficiencies at least...

Using just a single one of those tends to end up problematic
at times but any two use to suffice.

Maybe firmware feature should be merged into kernel feature
as the firmware binaries added by it are only used by kernel
but let's clean up a bit at a time.

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

+net-eth covers both stage2 and base installation parts
while use/stage2/net-eth would result in an inobvious
catch when udev-rule-generator-net would hit install2
but not the installed system, and interface bindings
would be carried over from installer to the installation
but would *not* be updated in case of changed network
card(s) configuration.