9cedefdba9
The features might get copy-pasted (or even copied-and-pruned) when initialized; there's an unneccessary duplication of the function name in the line adding it to FEATURES list, thus prone to being forgotten and causing some havoc later on. It was wrong in the first place but tackling this with some double-colon rules ran into terminality issues, and further tortures were considered unneccessary. The current solution isn't perfect (no completely transparent function name registration upon corresponding target being called) but at least it is an improvement... |
||
---|---|---|
.. | ||
main/scripts.d | ||
config.mk | ||
generate.mk | ||
generate.sh | ||
README |
Этот каталог содержит "заготовку" фичи в качестве примера и должен дать представление о том, какой код _может_ быть включён в настоящую фичу: статические файлы, два makefile для создания конфигурации и генерирования части профиля, а также шелл-скрипт для такого генерирования. Вовсе не требуется втягивать всё в свою фичу: лучше постараться сделать её минимальной, самодостаточной и полезной в качестве "кирпичика". Единственной обязательной частью фичи является файл config.mk, который включается в distro.mk верхнего уровня и предоставляет цель вида use/*, специфичную для данной фичи, а также добавляет её в переменную FEATURES. Если название фичи не упоминается в списке, содержащемся в этой переменной, то она не задействуется при построении профиля, а только при сборке конфигурации. Остальное содержимое является дополнительным и используется в таком порядке (см. ../Makefile): - сперва в $(BUILDDIR)/image/ копируются все подкаталоги, соответствующие итоговым именам субпрофилей, запрошенных для профиля образа; при этом они сливаются с деревом, которое уже сформировано субпрофилями (../sub.in/*) и уже скопированными фичами; если какие-либо файлы перекрылись по именам, rsync должен оставить резервные копии (*~), которые должны просигнализировать о беспорядке; - запускается generate.sh, если существует и исполнимый; - применяется generate.mk, если существует и непустой. Например, если используются субпрофили stage1, stage2/install2 и main, можно решить собрать специфические для фичи скрипты инсталятора в install2/image-scripts.d/ (или необходимые для операций с пакетной базой -- в main/scripts.d/, смотря чего надо добиться; загляните также в документацию mkimage). А если требуются нетривиальные действия по конфигурированию (как при сборке syslinux.cfg из кусочков, в зависимости от того, что из запрошенных модулей оказалось в наличии) -- то их можно произвести из generate.sh и generate.mk. Пожалуйста, присылайте отзывы о (бес)полезности кода в этом каталоге mike@altlinux.org.