[devel-distro] RFC: profiles/pkg/lists/README
Michael Shigorin
mike at osdn.org.ua
Mon May 11 21:36:52 MSK 2009
Здравствуйте.
Набросал тут на даче драфт по части использования различных групп
пакетов и метапакетов при построении дистрибутивов; просьба
посмотреть и отозваться, что ещё забыл или не знал.
Этот же файлик в utf-8 пойдёт как profiles/pkg/lists/README,
если не будет особых возражений.
PS: просьба Cc: личной почтой, опять не особо до рассылок.
--
---- WBR, Michael Shigorin <mike at altlinux.ru>
------ Linux.Kiev http://www.linux.kiev.ua/
-------------- next part --------------
Политика составления и поддержки списков пакетов
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Файлы со списками пакетов могут быть ценной информацией о том,
какие их группы уместно добавлять в дистрибутив или установленную
систему вместе. Этим они отчасти дублируют метапакеты, но являются
намного более "мобильными" (для модификации списка достаточна правка
файла без дополнительной сборки метапакета; для публикации -- git push,
а не ожидание публикации обновлённого репозитория) и более удобными
для подборок, не являющихся тесно связанными по майнтейнеру (%name-*).
Для возможности использования в качестве устанавливаемой группы пакетов
следует создать соответствующий файл ../groups/*.directory подобно уже
существующим.
При оценке степени задублированности имеющихся списков может быть полезен
скрипт bin/pkgdups.sh (от корня профиля).
Предлагаются такие соображения по выбору "метапакет, групповой список
или просто список" в форме потенциальных плюсов и минусов вариантов:
метапакет ("в уме" glibc):
+ объединяется тесная группа родственных (под)пакетов
+ в совместной поддержке одним и тем же майнтейнером или группой
+ состав группы скорее статичен (например, меняется раз в пару лет)
- индивидуальные пакеты часто или надолго "вылетают" из репозитория
или имеют существенные различия в именовании/зависимостях между
различными ветками (что чревато развалом сборки дистрибутива или
неожиданным изменением его свойств)
групповой список ([firefox, firefox-ru]):
+ объединяется умеренно связная группа подпакетов
+ состав группы может изменяться в зависимости от конфигурации
дистрибутива (макроподстановки по *.in)
+ в группу полезно включить пакеты, которые могут быть ситуативными
или достаточно "вредными" по сборке, чтобы было сложно ожидать их
наличия в нужном бранче репозитория
+ указанную группу пакетов имеет смысл дать возможность устанавливать
одним блоком в уже установленную систему (alterator-pkg)
- может потребоваться удаление включённых в групповой список пакетов
с целью умещения дистрибутива в объём носителя (CD, flash)
[TODO: проверить взаимодействие с исключением пакетов: 'package-']
- сейчас требуется делать use-* в use.mk.in или profiles/*/Makefile.in
для собственно задействования дополнительных групп [с зависимостями]
простой список (base-kde-cd):
+ непосредственно влияет на состав дистрибутива, в котором применяется
(что особенно ценно при шлифовке перед выпуском)
+ количество таких списков невелико
- объём таких списков существенен
- имеется существенное дублирование [блоков] компонентов между списками,
что приводит к повышению затрат времени и спокойствия при необходимости
изменений в таких компонентах и уменьшает внутреннюю реюзабельность
Есть также некоторая невнятная задумка по части тегирования списков
(например, пометить список как 'base'+'firefox' или 'firefox'+'addons'),
но пока не совсем понятно, что именно с таким делать (./configure --with).
Одним из вариантов реализации для двумерности (base/disk/... + $whatever)
могут быть каталоги с симлинками на содержимое profiles/pkg/lists/.
More information about the devel-distro
mailing list