READMEs: pkglist related clarification

glebfm@ asked what to do with new package lists: whether these
belong to features, or to distributions themselves.  This question
is actually open and up for discussion but there are guidelines
that can and should be written down already; and so they were.

Added pkgdups utility reference as well.
This commit is contained in:
Michael Shigorin 2012-04-09 22:18:31 +03:00
parent acaf12c34e
commit f4519332e9
3 changed files with 17 additions and 0 deletions

View File

@ -32,3 +32,14 @@
- $$(VAR) раскрываются позже, при включении $(CONFIG) и востребовании - $$(VAR) раскрываются позже, при включении $(CONFIG) и востребовании
значений; в этом случае их значения могут изменяться до окончания значений; в этом случае их значения могут изменяться до окончания
конфигурации, а также зависеть от значений других переменных конфигурации, а также зависеть от значений других переменных
По спискам пакетов:
- на этапе экспериментирования можно забивать прямо в описание образа
- при фиксации состояния стоит воспользоваться существующими списками,
а дополнительные оформить как можно более чётко обособленными по тем
задачам, для решения которых они и подобраны
- повторяющиеся логически связанные группы списков может иметь смысл
выделить в фичу (см., например, power или x11)
- если явной фичи не наблюдается, но у группы дистрибутивов намечается
заметная общая часть -- её можно выделить в промежуточную цель вида
distro/.name, не являющуюся самостоятельно собираемой

View File

@ -8,3 +8,9 @@
Подкаталог tagged/ содержит тегированные списки, имена которых Подкаталог tagged/ содержит тегированные списки, имена которых
удобно получать функцией tags() (см. ../../lib/functions.mk). удобно получать функцией tags() (см. ../../lib/functions.mk).
Для выявления дубликатов в составе списков служит запускаемый
с указанием перечня анализируемых файлов скрипт ../../bin/pkgdups;
пытаться избежать дублей на 100% скорее бесполезно, но бродячие
устойчивые группы пакетов могут заслуживать выделения отдельным
списком.