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 Мне показалось, что Вы придаете очень большое значение тому, чтобы пакет > использовался в именно той среде, в которой он был собран. Я хотел бы > спросить, почему Вы так считаете, а также каким образом внедрение описанного > Вами в [ftp://ftp.altlinux.org/pub/people/at/protva-2008.pdf] метарепозитария > может изменить текущую ситуацию. Пакет может использоваться в другой среде, если позволяют зависимости. Так что я не бегаю за людьми и не объясняю им, можно им ставить пакеты вопреки хронологической последовательности или нет. Я говорю о базовом принципе формирования целостного репозитария. Нужно учитывать, какой пакет после какого собрался, и как это повлияло на всё остальное. Тогда мы имеем "историю коммитов" в репозитарии (вполне по аналогии с git) и можем отслеживать взаимное влияние между пакетами на очень тонком уровне. Сейчас репозитарий формируется лишь с довольно слабыми проверками целостности, а о взаимном влиянии между пакетами мы узнаем при еженедельной пересборке пакетов. Так что если пакет перестал собираться, а в его сборочной среде изменилось более одного пакета, тогда возникает двусмысленность: какой из обновившихся пакетов сломал сборку? А при правильном подходе разлом по сборке будет автоматически отслеживаться с минимальной возможной грануляностью (то есть на уровне пакета, если только не была затребована транзакция пачки пакетов). Идея метарепозитария (и соответствия его настоящему репозитарию) несколько сурова, но она правдива, и она даёт гарантию и полную настоящую картину развития репозитария. По-видимому, эта идея должна относиться только к базовому "репозитарию"/"бранчу" (напр. как сейчас 4.0). На основе базового репозитария можно сделать другие "пост-фактум репозитарии" (как school-4.0), где метарепозитарий не играет роли, а пакеты туда перекладывает вручную мистер Икс.