[devel-distro] RFC: package list tags

Michael Shigorin mike at osdn.org.ua
Thu Aug 13 21:37:49 MSK 2009 

	Здравствуйте.
Заранее прошу прощения за объём текста, но такова уж задача.
Спасибо тем, у кого хватит терпения не только прочитать и
обдумать, но и посмотреть и высказаться, а то и применить.


о чём речь
~~~~~~~~~~

Мысли о том, что mkimage-profiles-desktop::profiles/pkg/lists/
достаточно густо населено, чтоб напоминать уже толкучку,
возникали ещё весной[1,2].

Дело отчасти в том, что списки не могут включать другие списки
и сейчас требуется явное указание имён списков пакетов на том
или ином этапе (благодаря use-% количество таких указаний уже
сократилось, но всё равно их ещё надо слишком много, чтобы делать
порезку более мелкой и не угробиться при обновлении makefiles).

Возможно, этот подход будет когда-нибудь реализован в mkimage
и будет полезен сам по себе, но имеется ещё один вариант:
тегирование списков пакетов и их подтягивание по набору тегов.

В бранче tags моего репозитория m-p-d это в некотором виде уже
реализовано, но остаётся ряд вопросов по тому, как лучше будет
пользоваться этой возможностью.  Потому и хочу посоветоваться.


что сделано
~~~~~~~~~~~

Созданы два скриптика:

* bin/lists2tags, который выковыривает из списков комментарии вида
  "# tags: tag1, tag2..." и строит плоское дерево каталогов с
  именами найденных тегов под pkg/tags/, заполняя его симлинками
  на сами списки; запускается из pkg/lists/Makefile или руками:
    pkg/lists $ PKGDIR=.. ../../../bin/lists2tags *
  (сейчас просто make tags не сработает, GLOBAL_PKGDIRS нет);

* bin/tags2lists, который выдаёт имена тех списков, которые
  содержат все перечисленные в командной строке теги; обёрнут
  функцией tagged в profiles/functions.mk, пример использования
  можно посмотреть в profiles/main/Makefile.in -- там есть
  тестовая цель и добавка к IMAGE_PACKAGES, которая ссылается
  на GLOBAL_BASE_TAGS и GLOBAL_DISK_TAGS, пока нигде не
  определяемые.

  Была мысль переделать с изначальных каталогов с симлинками на
  файлы со списками имён пакаджлистов, но это чуточку удобней в
  tags2lists и сильно неудобней в lists2tags -- в т.ч. пришлось
  бы вручную обеспечивать уникальность вхождений -- а также при
  просмотре tags/ глазами (плюс симлинки могут пойти в ход и не
  так, как я предполагал).  Также вариант с каталогами включает
  возможность иерархических тегов, в отличие от файлового.

  Ещё изначальная реализация подразумевала игнорирование тегов,
  для которых не существует каталога под tags/ (без автосоздания)
  -- но посоветовавшись с led@, решил сделать не так строго.

Также сделаны необходимые мелкие правки в нужных makefiles
и добавлено заполнение @TOPDIR@ в configure.ac.

Раскиданы изначальные теги по _группам_ списков пакетов.
Они заведомо несовершенны и, возможно, ещё непригодны к
использованию как есть, и это ещё один из вопросов.

Всё это кратко добавлено в README.


что ясно
~~~~~~~~

Как тегировать списки?  Тут пока ясно одно: разводить ещё один
уровень опосредованности, тегируя как "icewm" список пакетов под
именем "icewm", содержащий одну строчку "icewm" -- излишне.

Надо:
* выработать пригодную для выборок и по возможности
  ортогональную категоризацию;
* добавить/поправить теги в списках, которые имеют общее;
* выделить в отдельные файлы и протегировать общие "кластеры"
  пакетов, ходящие по куче разных списков (тж. bin/pkgdups.sh).

Пока в качестве свойств и возможных значений могу предложить такие:

компонент: base, disk(?), addon, contrib, live(?)
  возможно, live стоит выделить в отдельный класс, не знаю

направленность(?): desktop, server
  эта категоризация может быть слишком грубой и притом
  слишком накладывающейся со следующим пунктом

разновидность: gnome, kde, xfce, [office, backup]
  вот здесь не особо понятно, см. тж. ниже

носитель: cd, dvd
  текущие списки *-lite тегируются как cd, полные -- как dvd,
  базовые -- как cd, dvd

архитектура: i586only, x86_64only
  слегка хотелось бы избавиться от @I586_ONLY@ в списках,
  потому как каждое такое вхождение приходится отмечать и в
  configure и вообще это всё как-то некрасиво; если вводить
  теги i586, x86_64, то придётся или совать их вместе в каждый
  список, который работает для всех наших платформ, или сперва
  наворачивать логику выборки от текущего простого AND по всем


что неясно
~~~~~~~~~~

Стоит ли думать в сторону иерархии тегов -- как-то:
  desktop desktop/kde desktop/gnome
  server server/office server/backup
или помимо необходимости продумывания и реализации видны иные
противопоказания?

Стоит ли делать полноценный язык выборки?  Особенно над этим
задумывался, расставляя "cd" и "dvd". (если да -- скорее всего,
придётся использовать sqlite)

Как этим всем пользоваться?  В принципе, сейчас можно попробовать
расставить и задействовать теги таким образом, чтоб заменить ими
GLOBAL_BASE_PACKAGE_LISTS сотоварищи, но практически я этого ещё
не доказал.  Пока кажется разумным использование в качестве
дополнения и плавное дробление сильно задублированных списков[3].

Возможно, когда-то получится нечто вроде такого:
- выбранный тип дистрибутива определяет базовый набор тегов
  (например, "desktop" -> kde);
- выбранный подвид -- дополняет или корректирует его
  (например, "gnome desktop" убирает kde, добавляет gnome);
- выбранный тип носителя определяет набор списков
  (например, для "cd" включаются только тегированные так);
- и уже где-то ближе к завершающему этапу располагаются ручки
  для точечной коррекции попакетно, поскольку понятно, что перед
  каждым выпуском утряхивать состав приходится оперативно и лучше
  иметь "последний довод релиз-менеджера" (tm), чем вылавливать,
  откуда что вдруг вылезло по зависимостям или тегам;
- см. тж. [4].

Пока не совсем понятно, где именно тут branding, но его возможно
и не засовывать именно сюда -- пусть себе наследуется от указания
дистрибутива или задаётся через --with-branding и дальше.

Ещё неясно, куда именно относятся вариации вроде школьности.
Поскольку дистрибутив из списков с практически любым набором
других тегов может иметь ещё и такое свойство _в дополнение_,
разве по части дизайна и документации -- возможно, в замену.

Открыт вопрос с тегом docs -- а нужен ли?


как пробовать
~~~~~~~~~~~~~

Втянув бранч tags из m-p-d у меня в git.alt[5], можно выполнить:
  autoconf
  configure
  cd profiles
  make test-tags 

-- предпоследней строчкой должно быть нечто вроде
  .../pkg/lists/base .../pkg/lists/kde
согласно тестовому списку в profiles/main/Makefile.in::test-tags.

При этом также будет выполнено построение симлинков под tags/,
можно сходить туда и полюбоваться.

Для каких-либо реальных действий, насколько пока думаю,
можно заполнять GLOBAL_BASE_TAGS и GLOBAL_DISK_TAGS в use.mk
или дёргать tagged() прямо из profiles/*/Makefile.in


ссылки
~~~~~~

[1] http://lists.altlinux.org/pipermail/devel-distro/2009-April/000280.html
[2] http://lists.altlinux.org/pipermail/devel-distro/2009-May/000337.html
[3] http://fly.osdn.org.ua/~mike/ALT/docs/whitelabel/reports/dups-20090813-uniq
[4] http://fly.osdn.org.ua/~mike/ALT/docs/whitelabel/whitelabel.PNG
[5] http://tinyurl.com/m-p-d-mike-tags


благодарности
~~~~~~~~~~~~~

Спасибо Вите Советову, а также eostapets@, led@ и boyarsh@,
принявшим участие в обдумывании этого безобразия и снимавшим
меня с разнообразных ручников в процессе; также и всем дочитавшим
до сих пор -- за терпение :-)

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

More information about the devel-distro mailing list