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 is about (a)synchronous package builder in fact.

- docs week
- deflogin: empty ROOTPW explicitly ignored (potential security fix)

That's how it evaded the rescue part of regular-sysv-tde.

Looking as how every .regular-sysv-gtk descendant ended up using
use/syslinux/ui/gfxboot by now it seems better to just stick it there.

use/deflogin will result in ROOTPW being exported no matter
is it set or not; xport() can't check before exporting as it
relies on lazy evaluation when the actual ROOTPW value can be
set or modified after exporting GLOBAL_ROOTPW for mkimage.

So let's not even pretent we can differ unset ROOTPW from
empty ROOTPW: both result in empty GLOBAL_ROOTPW as of today.

Fixing this would require moving the exports into a separate
makefile being included after all the configuration and checking
each variable for being defined before exporting the corresponding
GLOBAL_ prefixed one.

Yes this might be a security fix in some cases.

It's preliminary but rather working by now;
one of the main woes is #29497 so far.

xterm has been overduplicated,
moved to pkglists for clarity.

TDE images are pretty modest regarding resource consumption
thus suitable for older hardware; a slower flash drive can
stall indefinitely showing slideshow and not going any further
with actual package installation so let's put a cap on that.

Added use/branding/slideshow/once as one of the uses
albeit the interface is universal; see this page for
more info: http://altlinux.org/branding/slideshow [ru]

The service and initscript have "connmand" name
while the package is called "connman" indeed.

Shame on me; this became apparent
while building regular-e18-sysv.

Speccyfighter asked for NTP support within sysv-tde flavour;
meant openntpd apparently, fixing up.

gnustep-AddressManager has been replaced
with gnustep-Etoile-AddressManager, ditto
gnustep-DictionaryReader; see also [ru]:

http://altlinux.org/?title=GNUstep%2FApplications&action=historysubmit&diff=28795&oldid=28694

Defining a one-time variable is useless in this case,
and README should state the undefined ROOTPW status
explicitly (since it's now as advertized, heh).

The goals listed are pretty important to have them ordered
by priority; collaboration is definitely more important
than dynamic range of release managers' experience.

Some more editing has been due over pkg.in/lists/tagged/README
to make it more comprehensible and up-to-date; the problem with
groups isn't actually that bad as alterator-pkg's groups concept
is currently aligned with the requisite functionality provided by
pkg.in/lists/* directly; the tagged pkglists come into play when
we want to add "something like that" and don't really care about
the fine details of a secondary thing trusting that it's actually
comprised and working as advertized through its name tags.

Compare to reusing the pre-existing image configuration or features
versus reimplementing things in a rigid manner -- it's a flexibility
vs predictability question, and both scenarios are supported within
m-p explicitly.

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.

A few readability fixes and lib/*.mk demotion since conf.d/*.mk
is now an established place for RM-written image configuration.

icewm.iso is an installer needing further hassle to try;
rescue.iso is immediately useful OTOH.

"Goals" paragraph ended up with all of list items on a single line;
a colon has been missing in another one.

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

Its name might still change through 1.1.x series
("userfs"?) but things like this should be mentioned
at least -- or superfluous references to neighbouring
entities should be removed.

It's required for NFS mounts but having a rescue image listening
to any non-localhost ports is too bad an idea, IMNSHO.

So let's fix this while spotted.

It's missing as of psi-plus-0.16.289-alt1.

Well, some of the maintainers clearly prefer t7/branch
to publish their works; at least GNUstep and TDE packages
are updated there and might migrate to p7/branch later.

No need to fight that, really.

- regular updates

Split development packages into dev+gnustep pkglist -- these are
worth including in "full" version but will need thorough testing
so as to present the tools to those who value these.

Some of user packages are problematic and shouldn't be included
right now; the problems are mostly of these kinds:

- app won't start (at all or effectively);
- useless for being too alpha quality/incomplete;
- menu file for a commandline app lacking any feedback;
- package lacks the dependencies needed;
- it's a LoginPanel ;-)

Thanks a lot to upstream authors, real@ the packager
and kostyalamer who prepared a lot of menufiles anyways!

Thanks glebfm@ for spotting that it's = instead of +=
as it goes in all the other places; I remember no good
reason to overwrite the potentially preexisting contents.

KVM and VirtualBox support packages are pretty tiny
but essential when these images get deployed within
virtual environments for any reason, let's add 'em.

It's been gfxboot-free but no user visible facility to select locale
has emerged through these years; it's been decided to put gfxboot
until some text chooser is available (thanks aen@ for discussion).

These have been requested by Speccyfighter:
http://lists.altlinux.org/pipermail/community/2014-February/681710.html

I don't see any reason to use systemd within VM images,
and it would stick its journal as a syslog implementation
when not ditched explicitly :-/

vm/altlinux-p7-vm-net is yet another bridge...

IOW one has every right to expect that package manager
is set up already in a networked virtual machine.

This has been prepared by real@ and kostyalamer,
thanks them both; still needs more QA though.

Renamed ve/altlinux-p7 to ve/altlinux-p7-ovz-generic for clarity.

This is a minimalistic ALT-based system installer tailored
for those who know how to bring up networking and apt-get
the packages they actually need; thanks frbrgeorge@ for
proposing the specification as well as sem@ and glebfm@
for discussion.

No mc, no glibc-locales, even no man and interactivesystem!
Packages included: apt basesystem openssh vim-console

PS: Sisyphus-based regular build is not the main goal though
thus the p7/branch {bri,klu}dge.

We want every regular installer to know more than ext4 apparently.

This image is largely a rebase of server-ovz.iso onto regular-server;
it's not feasible to provide a single image that would install either
"mini" server or openvz/kvm one based on user choice during boot alas
(even if both ovz-el and std-def kernels are provided within "ovz" ISO
and vzctl&co could be stuffed into a package list/group).

Maybe this is fixed some day...