[devel] Q: personal package repositories: user PoV

["Dmitry V. Levin" <ldv@altlinux.org>]

[-- Attachment #1: Type: text/plain, Size: 7193 bytes --]

On Wed, Dec 28, 2011 at 03:50:58AM +0400, Vitaly Lipatov wrote:
> Одно не понимаю. Почему карманы давно разработаны sin@,
> и в Etersoft используются уже года полтора, а в devel@ всё
> вздыхают о том, что хорошо бы они были...

[карманы - это персональные репозитории пакетов, представляющие собой
дополнения к некоторому базовому репозиторию типа Sisyphus]

Оставляя в стороне технический аспект реализации системы сборки
таких репозиториев, предлагаю подумать вот на какую тему.

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

Устанавливать пакеты из такого репозитория можно либо с автоматическим
разрешением зависимостей (с помощью apt-get, подключив этот репозиторий в
качестве источника для обновления), либо вручную (скачивая и устанавливая
пакеты с помощью rpm).

Что происходит, когда некоторое непустое подмножество пакетов персонального
репозитория пересобирается (из того же исходного кода, из которого они были
собраны ранее) либо по явной команде мейнтейнера, либо в результате
автоматической процедуры, которая выявляет изменения сборочной среды
пакетов?  Как и в случае повторной сборки test-only задания, в результате
пересборки персонального репозитория свежепересобранные пакеты оказываются на
месте собранных ранее, причем имена файлов пакетов и их ключевые
характеристики (NSVR: %name, %serial, %version, %release) с высокой
вероятностью остаются прежними.

В какой ситуации оказывается пользователь, который установил пакеты из
этого персонального репозитория до пересборки?  Поскольку NSVR
пересобранных пакетов не изменились, обновить установленные пакеты будет
непросто - "apt-get dist-upgrade" не поможет, остаются ручные режимы:
либо "apt-get reinstall" с явным указанием списка пакетов, либо rpm
(скачивание всех пакетов персонального репозитория с последующим "rpm -F")

Ситуация, в которой оказывается пользователь пересобранного персонального
репозитория, становится совсем сложной, когда у пересобранных пакетов
существенным образом меняются зависимости (например, в результате
пересборки из-за soname change в базовом репозитории, или чего-нибудь
подобного).  В этом случае dist-upgrade вынужден предложить пользователю
удалять пакеты, "rpm -F" может не справиться из-за неудовлетворенных
зависимостей, и обновить ранее установленные пакеты (особенно если их было
достаточно много) из персонального репозитория становится совсем непростой
задачей, сваливать которую на пользователя просто неправильно.

Какие могут быть варианты решения этой проблемы обновления из
персонального репозитория?

1. Полный отказ от функциональности по пересборке пакетов без изменения
исходного кода.  Это настолько неудобно для разработчика, что, на мой
взгляд, этот вариант совершенно не реалистичен, и его можно отбросить
сразу.

2. Автоматическое изменение NSVR пересобираемых пакетов самой сборочной
системой по некоторым правилам.  На практике это, скорее всего, означает
изменение %release пакетов.  Поскольку в большинстве пакетов %release
указан в спек-файлах явно, это, очевидно, означает редактирование
спек-файлов сборочной системой, что сопряжено с известными техническими
трудностями (у нас разработаны специальные инструментальные средства для
автоматического увеличения релиза, которые охватывают большинство
существующих пакетов, но в общем случае эта задача, как известно, не имеет
решения), и в качестве побочного эффекта приводит к изменению исходных
пакетов.  Мне этот вариант, опирающийся на решение задачи, не имеющей
решение, не нравится.
Альтернативно, можно предложить всем мейнтейнерам формировать %release
с помощью макроса, который сборочная система могла бы использовать для
автоматического увеличения %release.  Оставляя за скобками вопрос о том,
что это мог бы быть за макрос, мне кажется сомнительным, чтобы ленивые
по своей сути мейнтейнеры справились бы с таким радикальным изменением
правил составления спек-файлов.

3. Добавление к NSVR пакета еще одной характеристики B.  Автоматическое
увеличение этой характеристики самой сборочной системой при каждой
пересборке пакета.  Сквозная адаптация всех инструментальных средств на
стороне пользователя (в первую очередь apt и rpm) для учета этой
характеристики B при обработке пакетов.  Тут возможны различные варианты.
Можно включать эту характеристику в имя файла собранного пакета, а можно
этого не делать.  Можно включать эту характеристику в пользовательские
интерфейсы выбора пакета (например, чтобы можно было указать ее для
уточнения пакета при вызове apt-get и rpm), а можно этого не делать.
Наконец, можно придумать для этой характеристики B какой-то новый тэг rpm,
а можно попробовать адаптировать какой-нибудь из уже существующих.
Чем больше будет таких мест, где сможет/будет фигурировать B, тем больше
рычагов управления будет у пользователя, с одной стороны, и тем сложнее
будет реализация и хуже обратная совместимость, с другой стороны.

4. На самом деле в rpm уже есть один тэг, который годится на роль такой
характеристики B.  Более того, значение этого тэга уже сейчас
автоматически увеличивается самой сборочной системой при каждой пересборке
пакета.  Более того, этот тэг уже сейчас rpm учитывает при обновлении
пакетов именно таким образом, как это нужно для решения нашей задачи: при
равенстве NSVR у ранее установленного и предлагаемого для обновления пакета
rpm соглашается на обновление, если у обновляемого пакета значение этого
тэга больше.  Этот тэг называется BUILDTIME, и его можно получить с
помощью rpmquery:
$ rpmquery --qf '%{BUILDTIME}\n' -p Sisyphus/files/x86_64/RPMS/rpm-4.0.4-alt100.45.x86_64.rpm 
1327518688
Поддержку учета BUILDTIME при обновлении пакетов я добавил в rpm
много лет назад, так что можно полагать, что у всех наших пользователей
она уже есть.
Впрочем, apt-get на данный момент не поддерживает BUILDTIME, нет способа
указать BUILDTIME при вызове rpm, и BUILDTIME не включается в имя файла
пакета.  Тем не менее, на мой взгляд, внедрение BUILDTIME в качестве еще
одной характеристики для автоматического обновления пересобранных пакетов
из персональных репозиториев выглядит наиболее перспективным вариантом.

Меня, впрочем, несколько настораживает перспектива выпуска этого джинна
из бутылки.  Как только персональные репозитории можно будет пересобирать
без изменения исходного кода и это перестанет доставлять неудобства
пользователя, так сразу возникнет желание распространить эту практику на
базовые репозитории типа Sisyphus, чтобы автоматически пересобирать пакеты
без изменения исходного кода, NSVR и записи в %changelog в тех случаях,
когда пересборка необходима (soname change и т.п.).  В этом случае
включение BUILDTIME в имена файлов собираемых пакетов кажется мне
необходимым, но что делать с отсутствием записи в %changelog, непонятно.

Вот такие соображения.  Теперь можно комментировать. :)


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]