Re: [devel] поддержка пакетов в git

[Alexey Tourbin <at@altlinux.ru>]

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

On Tue, Sep 30, 2008 at 05:55:11PM +0400, Ivan A. Melnikov wrote:
> > У меня теория и модель несколько более размыты.  Рассмотрим постулат
> > теории B(S,C)->P, который описывает некий базовый способ преобразования
> > символов.  Интерпретация состоит в том, что функция B осуществляет
> > сборку пакета S в среде C, а на выходе даёт собранные пакеты P.

> > Короче, почти все соображения о том, чтобы "варить" пакеты и вообще
> > о "стабилизации" и "перекладывании" являются неправильными, потому
> > что они пытаются игнорировать базовый принцип действительности
> > (преобразования исходников в собранные пакеты, с фиксацией параметров
> > преобразования).
> 
> Попробую возразить,  а то такая дискуссия заглохла...
> 
> Пакеты собираются для того, чтобы ими можно было пользоваться. К сожалению, 
> достаточно сложно формализовать набор условий, при выполнении которых пакет 
> может считаться полезным с этой точки зрения. Наиболее достоверным 
> свидетельством того, что пакетом можно пользоваться, на данный момент, на мой 
> взгляд, приходится считать тот факт, что им кто-то пользуется.
> 
> С этой точки зрения пакет, пролежавший месяц в Сизифе, в среднем лучше, чем 
> пакет, только что собраный туда, несмотря на то, что последний собран в более 
> актуальной среде.
> 
> Безусловно, такая точка зрения игнорирует Базовый принцип действительности, 
> однако не противоречит ему. Более того, становится ясно, что для формирования 
> бранчей перекладывание предпочтительнее пересборки. 

Был по крайней мере один серьёзный прокол с перекладыванием пакетов
(где-то год назад): пакет amarok при перекладывании из Сизифа в 4.0
стал вываливаться с undefined символами.  И этот случай мог бы стать
далеко не едиственным, потому что Си+плюс ABI -- вещь особенно хрупакая.
Для просто Си ABI отслеживать несколько легче, но это всё ещё требует
ручной работы, а надёжной гарантии на уровне зависимостям не даёт.

Перекладывание "предпочтительнее" в смысле удобства, но не в смысле
гарантии целостности.

Собранный пакет P неявно ссылается на ту среду C (чрут), в которой он
был собран.  Принцип обратной совместимости можно формализовать через
частичное упорядочение: в новой среде C1>C пакет P будет работать в силу
обратной совместимости (что фактически и происходит при поступлении
новых пакетов в сизиф; мы же не делаем полную замещающую пересборку всех
пакетов, у которых обновилась сборочная среда).  А перекладывание в
бранчи означает прямо противоположную ситуацию: в более старой среде
C0<C никакой обратной совместимости быть не может (само понятие обратной
совместимости здесь неприменимо).

Короче, с точки зрения модели мы можем надяться на обратную
совместимость (что позволяет не делать полной замещающей пересборки
пакетов), но не можем надеяться на "прямую" совместимость, которая
позволяла бы перекладывать пакеты в более старую среду.

Требование можно расслабить для noarch пакетов, потому что для них
невозможны проколы на уровне ABI вроде случая с amarok.  Правда, можно
придумать нежелательные ситуации и для noarch пакетов (напр. lzma сжатие,
и вообще какие-либо предварительные требования к среде).

> Мне показалось, что Вы придаете очень большое значение тому, чтобы пакет 
> использовался в именно той среде, в которой он был собран. Я хотел бы 
> спросить, почему Вы так считаете, а также каким образом внедрение описанного 
> Вами в [ftp://ftp.altlinux.org/pub/people/at/protva-2008.pdf] метарепозитария 
> может изменить текущую ситуацию.

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

Я говорю о базовом принципе формирования целостного репозитария.
Нужно учитывать, какой пакет после какого собрался, и как это повлияло
на всё остальное.  Тогда мы имеем "историю коммитов" в репозитарии
(вполне по аналогии с git) и можем отслеживать взаимное влияние между
пакетами на очень тонком уровне.  Сейчас репозитарий формируется лишь
с довольно слабыми проверками целостности, а о взаимном влиянии между
пакетами мы узнаем при еженедельной пересборке пакетов.  Так что если
пакет перестал собираться, а в его сборочной среде изменилось более
одного пакета, тогда возникает двусмысленность: какой из обновившихся
пакетов сломал сборку?  А при правильном подходе разлом по сборке будет
автоматически отслеживаться с минимальной возможной грануляностью (то
есть на уровне пакета, если только не была затребована транзакция пачки
пакетов).

Идея метарепозитария (и соответствия его настоящему репозитарию)
несколько сурова, но она правдива, и она даёт гарантию и полную
настоящую картину развития репозитария.  По-видимому, эта идея должна
относиться только к базовому "репозитарию"/"бранчу" (напр.  как сейчас
4.0).  На основе базового репозитария можно сделать другие "пост-фактум
репозитарии" (как school-4.0), где метарепозитарий не играет роли, а
пакеты туда перекладывает вручную мистер Икс.

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