Mkimage-profiles/style: различия между версиями

Материал из ALT Linux Wiki
м (own cat)
Строка 13: Строка 13:


Если совсем какая-то специфика, но может пригодиться и другим <small>(косясь на mithraen@ и asterisk-1.6.[012] в m-p-d)</small> — может иметь смысл завести «свой» namespace для списков/фич.
Если совсем какая-то специфика, но может пригодиться и другим <small>(косясь на mithraen@ и asterisk-1.6.[012] в m-p-d)</small> — может иметь смысл завести «свой» namespace для списков/фич.
== выбор уровня воздействия ==
При сквозном наследовании стоит [http://git.altlinux.org/people/mike/packages/?p=mkimage-profiles.git;a=commitdiff;h=c5e559b7b9eb4bd0a72bc89961e83fdb33c13dc3 тщательно] выбирать место, где ''уже'' нужно сконфигурировать то или иное свойство образа.  Например, включение {{pkg|icewm}} в <tt>live-icewm.iso</tt> следует произвести на этапе конфигурации дистрибутива в {{path|conf/live.mk}}, а не, скажем, на этапе конфигурации фичи в {{path|features.in/live/config.mk}}; при этом если крупный фрагмент конфигурации ''является'' реюзабельным, может иметь смысл вынести его в отдельную фичу.


== построение вместо урезания ==
== построение вместо урезания ==

Версия от 00:15, 20 декабря 2011

Рекомендации по стилю mkimage-profiles

строгое обращение с потоками данных

Желательно направление движения значений переменных и действий короткими шагами «сверху вниз» — без выдёргивания значений из соседних каталогов или путешествий сверху в самый низ различным образом).

Построение списков пакетов «на лету» обдумывается, но не подобными хаками, а скорее такими (см. создание .base; также реализована выборка пакаджлистов по произвольным булевым выражениям, включающим теги).

унификация

Крайне желательно неразведение зоопарка аналогов (например, методов макроподстановки). Если вводятся новые практики или концепции, лучше предварительно обсудить задумку или реализацию в своём бранче next до того, как на новосделанное будет завязано много ценного. Если возникают конфликты мнений — давайте постараемся их разрешать, а не форкаться без планов на мерж.

повторное использование вместо дублирования

Также и в самих списках сколько получается — давайте стараться избежать дублирования, а вместо мини-форков выделять общее и отделять разное.

Если совсем какая-то специфика, но может пригодиться и другим (косясь на mithraen@ и asterisk-1.6.[012] в m-p-d) — может иметь смысл завести «свой» namespace для списков/фич.

выбор уровня воздействия

При сквозном наследовании стоит тщательно выбирать место, где уже нужно сконфигурировать то или иное свойство образа. Например, включение icewm в live-icewm.iso следует произвести на этапе конфигурации дистрибутива в conf/live.mk, а не, скажем, на этапе конфигурации фичи в features.in/live/config.mk; при этом если крупный фрагмент конфигурации является реюзабельным, может иметь смысл вынести его в отдельную фичу.

построение вместо урезания

При возможности следует выбирать подход «построить из нужного», чем «добавить всякое и выбросить ненужное»: он гораздо лучше ложится на идею mkimage-profiles (создание из кусочков и минимизация непрозрачных хаков). Это позволяет надеяться на трассируемость процесса построения дистрибутива.

Вынужденным исключением на сейчас являются:

  • фича install2 с зачисткой излишних модулей ядра и файлов в компактном livecd-корне инсталятора;
  • фича cleanup, подготавливающая постинсталяционную зачистку лишних пакетов в свежеустановленной системе.