[devel-distro] Наследование профилей в mkimage-profiles

[Michael Shigorin]

On Sun, Sep 09, 2012 at 03:37:23AM +0700, Michael Pozhidaev wrote:
> >> Файлы разных дистров хорошо раскладывать строго как отдельные файлы.
> > Так загляни всё же в conf.d/ :)  Фичи тоже можно делать "именные",
> > мало того, в плане ещё и иерархические (подготовка к которым
> > уже началась: b21353a00c5a8163111833b7d9009332f182fe54).
> Заглядывал, всё норм. Так вот, заглядываю в pkg.in, там списки
> пакетов. Туда будут попадать списки пакетов всех сборщиков?

Да.  Но там прямщас можно namespaces -- или свой подкаталог
(самое надёжное), или "именной" тег (а вот тут нюансы:
a+b, a+b+c и a+b+MYTAG все попадут под выборку "a && b").

> Опять та же проблема: если некоторый сборщик  изменил свой
> список, а я его использовал, в моём дистрибутиве рождается
> непредсказуемая ситуация.

Предполагается, что по "чужим" основаниям и тегам подбирается
конфигурация общего плана, а своя обязательная фиксируется
жёстко и в явном виде.  То есть всё естественным образом.
Здесь пока самый неприятный вопрос -- "на вычитание".

Добавил в HOWTO абзац следующего содержания:

---
Следует заметить, что одной из основных идей метапрофиля является
возможность комбинирования "неопределённости" в заданном
направлении (часть задачи, формулируемая примерно как "нужен
livecd") и точности в том, где есть конкретные требования
(например, "firefox версии 10").  Выражается это в том, что можно
основываться на уже существующих образах и фичах либо построить
всё почти с нуля; можно брать существующие списки пакетов, а
можно жёстко задать свои. Разумный баланс (точнее, его пределы)
для каждого образа могут быть свои, но как общее правило -- для
"любительских" проектов и семейств образов стоит смелей
пользоваться наследованием, а вот "ответственные" образы может
быть лучше конфигурировать с явным заданием необходимой пакетной
базы (и в будущем -- юнит-тестов, которые надо утащить из m-p-d).
--- http://www.altlinux.org/Mkimage/Profiles/m-p/howto

> Или можно так, чтобы там лежали забетонированные списки,
> которые меняются только с явным анонсом и обсуждением, а списки
> отдельных сборщиков лежали бы где-то в отдельных каталогах?

Да, конечно.  Возможно, отрастут "платформы" (не путать с бранчами
-- разницу в m-p, соответствующую бранчам, IMCO лучше поддерживать
отдельными гитовыми ветками с внимательным cherry-pick при нужде).

И в любом разе можно бетонировать списки в своём пространстве
имён, даже если они будут содержать заведомые дубли.

  Кстати, инструментарий для отлова дублей можно взять
  в m-p-d::bin/pkgdups.sh; также оттуда думаю утащить
  bin/check-pkg-list, но пока не придумал, как бы сразу
  с порождаемыми aptbox интегрировать.  Возможно, лучше
  в mkimage делать.

> Если я пока ещё плохо просёк философию, то прошу прощения,
> но эти вопросы кажутся совсем не такими уж маловажными.

Мне тоже.  Пока ты идёшь по уже продуманному и сделанному :)

-- 
 ---- WBR, Michael Shigorin <mike at altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/
 ----        Sep 29, Kiev, Ukraine:
--       http://conference.osdn.org.ua