IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
The existing implementation would handle kernel differences
just fine but a bit too automatically: if it sees xz support,
that's what will end up being used (and if there's -Xbcj binary
compression filter available for the target platform, it will
be applied unequivocally either).
It's perfectly suitabe for getting fine-tuned release images
but is also a bit too resource-consuming while developing the
image configuration which has no business with its compression.
The one and only knob is SQUASHFS (see doc/variables.txt);
to give an idea of the differences, here are some numbers
for a mostly-binary (43% as per 99-elf-stats) webkiosk livecd
and a rather less so (18%) flightgear one on a dual quad-core
X5570 node (each mksquashfs run used up all the cores):
SQUASHFS | live-webkiosk.iso | live-flightgear.iso
---------+-------------------+---------------------
fast | 3:30 / 130M | 5:11 / 852M
normal * | 3:37 / 100M | 5:35 / 688M
tight | 3:50 / 98M | 6:47 / 683M
Thus if the knob isn't fiddled with, the defaults will allow
for a reasonably fast build of a pretty slim image; if one is
building a release or if a particular image is very sensitive
being close to the media capacity then just add SQUASHFS=tight
and see it a percent or two down on size.
Please note that lzo/gzip-compressed images are also quicker
to uncompress thus further helping with test iterations.
Thanks to led@ and glebfm@ for helpful hints and questions.
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
Этот каталог содержит т.н. фичи (features, особенности) --
каталоги, содержимое каждого из которых реализует одну из
подключаемых автономных возможностей образа.
Каждая фича должна содержать задействуемый при построении
конфигурации будущего образа файл config.mk, включаемый
в ../main.mk; он может описывать одну или более целей
вида use/*, дополняющих конфигурацию, и при наличии
дополнительных хуков для копирования или generate.*
обязан добавить имя фичи в $(FEATURES), для чего
создана функция add_feature без аргументов.
На этапе генерации сборочного профиля фичи рассматриваются
после инициализации профиля (см. ../image.in/) и копирования
субпрофилей (см. ../sub.in/). Для каждой фичи, указанной
в $(FEATURES), копируются подкаталоги сообразно субпрофилям,
а также производится обработка {image-,}scripts.d/; затем
выполняется скрипт generate.sh и задействуется generate.mk
(при их наличии).
Если фича дополняет хуками семейство целевых субпрофилей,
построенных на одном базовом, можно воспользоваться подкаталогом
с именем исходного базового субпрофиля (см. $src, $dst в Makefile).
Наиболее употребительные цели можно снабжать "ярлычками" вроде
"+icewm" с тем, чтобы сделать более краткими и выразительными
использующие их правила. Просьба не злоупотреблять количеством.
Каталог lib/ является специфическим для фич, определяющих
построение конкретного вида образа -- см. build-*/.
Несложный пример содержится в 00example/, более близкий к жизни
и нынешним пределам возможностей метапрофиля -- в syslinux/.
fe58c46ead