The implementation goes the shim[1] way as described here[2];
many thanks to Matthew Garrett and Rod Smith.

[1] http://mjg59.dreamwidth.org/20303.html
[2] http://www.rodsbooks.com/efi-bootloaders/secureboot.html

All of these individual packages should get sorted out
and shifted to pkglists at some time.

Suggested by rom_as@; see also #25713 at the moment.

Thanks aris@ for advice again.

It's not e17-default alone right now, gnome-icon-theme package
appears requisite at the moment so that menus and IBar aren't
half-empty regarding graphics.

Thanks aris@ for the advice and lots of patience with me.

ifconfig(8) was requested by rom_as@ and someone at opennet too.
It's legacy but habits are valuable nevertheless.

...instead of preliminary "statically linked" bits.

The creeping wireless bits should be thrown together,
including kernel modules, firmware, CLI/GUI controls,
and any plumbing required.

So far it's what should be tested, after all...
and #27941 is not so clearly about the kernel.

This should really be done in e17-default but until it's there...
(thanks aris@ for advice)

The things like fdisk are very useful on a livecd/liveflash
to carry in one's pocket indeed.

Just drop it from this pkglist.

Thanks someone for feedback:
http://www.opennet.ru/openforum/vsluhforumID3/88025.html#285

UEFI support is pretty requisite by now;
and el-smp hasn't seen updates for almost
half a year by now so an actively maintained
one is clearly preferred.

- regular images

See http://www.altlinux.org/Регулярные_сборки_образов
for the idea behind this set of images; in short, it's
*not* a bunch of polished end-user distros in a moment
but rather to facilitate Sisyphus package base testing
in as-is state during branch pre-release time.

It shouldn't overwrite the pre-existing configuration
but should fire if there's none.

Was long overdue already but let's leave that in 2012. :)

This one provides apt configuration for the LiveCD itself
as well as extra hooks for a livecd-install made system.

Installable live systems can have LUKS as well
and it's welcome addition to rescue images too.

This time it's

  xorriso : FAILURE : -volid: Text too long (33 > 32)

and todo-- as well.

It's a separate installation step to set the LUKS password;
see also #28200 for (terse) discussion and instructions on
getting this actually working for a distro.

For MATE regular images right now
but should be more widely useful.

Thanks gns@ for his help in figuring these out;
some metapackage related optimization is still due.

These are out there in Sisyphus and should be used
instead of copious lines in a package list.

Thanks sem@ for proposing gnome-icon-theme to supplement
the lack of icons in the default theme; note that tango
set doesn't quite cut it, even with extras.

Thunar -> thunar; xfcalendar -> orage

Borrowed from m-p-d's init-xdg-user-dirs, of course.

Slowly fixing up the discrepancies...

There's use/x11/kde already but that serves somewhat different
purpose as of today; the naming issue (kde vs kde4) was tersely
discussed with sin@ at the time of the merge of his KDE4 image
related bits and it's still not that clear.

Let's try this way and see if existing images would be ported
to use/x11/kde4.

This marks 0.17.0 hitting Sisyphus to much delight.

A few things have changed...

The whole live-rescue needs a massive facelift regarding
applications included and user experience achieved (remember
that folks are going to be stressed enough already with data
lost or system(s) not booting, and probably offline as well);
but at least it's UEFI bootable now.

The rescue feature intentionally doesn't pick up THE_PACKAGES
and THE_LISTS into stage2, so add EFI ones explicitly.

It was long overdue since (U)EFI support for live images
has been there for some six weeks or so already.

The (funny but somewhat confusing) problem manifests itself as

  E: Couldn't find package Binary

during a build run in the profile where a tagged packagelist
referenced by a specific target being built is open with vim
(which results in .FILE.sw? temporary file lying aside).

The script hook naming advice and "+name" puropose explanation
seem to have been missing.

There's a possibility to run into IA32 EFI but that's rather
uninteresting hardware (ancient Xeon servers and <s>outdated</s>
early Intel Mac laptops).  Just drop it on the floor.

As x86_64 UEFI support would result in "2D hybrid(r)(tm)" image
which boots with all combinations of BIOS/UEFI by CD|DVD/Flash
(or at least should boot), some downgrace seems due: use/efi will
turn use/isohybrid on non-x86_64 -- which will require further
tweaks on PPC/ARM some day.