[devel-distro] RFC: package list tags

[Michael Shigorin]

On Mon, Aug 17, 2009 at 12:09:03PM +0400, Anton V. Boyarshinov wrote:
> > Возможно, когда-то получится нечто вроде такого:
> > - выбранный тип дистрибутива определяет базовый набор тегов
> >   (например, "desktop" -> kde);
> > - выбранный подвид -- дополняет или корректирует его
> >   (например, "gnome desktop" убирает kde, добавляет gnome);
> > - выбранный тип носителя определяет набор списков
> >   (например, для "cd" включаются только тегированные так);
> Вот тут, мне, честно говоря, видится проблема. Дело в том, что
> отнесение того или иного списка к тому или иному дистрибутиву,
> строго говоря, совершенно произвольно. И то, что в одном
> дистрибутиве будет на dvd, в другом -- на cd..

Тоже да, но я тут не имел в виду жёсткость привязки, что ли.
Эт всё обсуждаемо :)

> Хотя, конечно, ничто не мешает держать в списках пакетов тэгов
> по числу дистрибутивов :D Правда, их будет даже больше, потому,
> что даже в одном дистрибутиве есть base/disk/live/groups и
> распихивание по ним пакетов в общем произвольно.

Хотелось бы тут как раз не "по числу", а иерархическим
наследованием -- как в http://www.altlinux.org/WhiteLabel
описывал.

Бишь что-то вроде
bare
`-> server-base
    `-> server-light
        `-> centaurus

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

Можно попробовать и с текущим m-p-d, но там реализация
(bin/tags2lists) умеет только AND по всем данным тегам.

Я тут подумал и решил, что проблема не только в тегах,
а и в том, что уж очень много у нас накопилось построенного
без внятной документации и самодокументированных примеров --
когда один так понял, другой этак, и в сумме разобраться
очень сложно.  Пытаюсь добить до полезного вида профиль,
написанный с нуля и ориентирующийся пока максимум на
объём server-light и icemaker, если получится -- дальше
думаю втащить centaurus.

Вот мысли, урывками набросанные в метро по ходу пьесы:

---
Возвращаясь к тегам: можно попробовать начать с простого --
сделать возможным автоматический подхват целевого дистрибутива из
@DISTRO@ и добавление специфических для него пакаджлистов,
например, минимальный общий для (почти) всех base плюс (теги)
base, server или base, runa (e.g. при сборке slinux просим base,
если существует slinux/base -- автоматически получаем и его).

При выделении общего предлагается пользоваться утилитой
bin/pkgdups.sh, которой в качестве списка аргументов передаются
списки для анализа.

"Болячкой" будет минимизация базовых списков с расслоением их на
нужное первой-второй-третьей очереди и разных вариаций (e.g.
gtk/qt), здесь важно не пропустить существенные регрессии по
итоговому составу основных дистрибутивов.  Но согласитесь,
nss_ldap в base.in -- это уже слишком.

Контрпример -- производные дистрибутивы с отличным именем,
которые "вдруг" теряют характерные для базового дополнения и
вынуждены копировать списки пакетов :(  Похоже, здесь всё-таки
понадобятся именно теги и возможность делать по ним полноценные
булевы запросы (есть реализация с "И" -- bin/tags2lists -- но её
применимость сильно ограничена).  При этом название дистрибутива
может быть автоматически добавляемо в список тегов (в отдельном
namespace, например, distro/).
---

-- 
 ---- WBR, Michael Shigorin <mike at altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/