Re: [devel] firefox-3.0 unmets (Sisyphus-20080709 x86_64 unmets: +54)

[Alexey Tourbin <at@altlinux.ru>]

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

On Thu, Jul 10, 2008 at 12:07:53PM +0400, Dmitriy M. Maslennikov wrote:
> 10.07.08, Alexey Tourbin<at@altlinux.ru> написал(а):
> > Вы хорошо осознали формулу B(S,C)->P ?
> Хорошо, и что?

Хорошо. :)

> >  Я утверждал, что пакет существует лишь как тройка <S,C,P>.
> А я утверждал, что удобнее когда не так.

"Не так" не бывает, потому что программа hasher реализует функцию
B(S,C)->P, и эта функция ложится в основу модели данных.

То есть, по-Вашему, удобнее не так, как есть на самом деле.
Но есть так, как есть на самом деле.

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

Нет, "исходники всех зависимостей" тоже были пропущены через функцию B;
и даже сам порядок, в котором они были пропущены, может дать неидентичный
результат сборочной среды C.

Значит, исходники "слишком исходны", чтобы идентифицировать что-либо
в конечном счете.  Предыдующая история сборки этих исходников продолжает
влиять слишком долго.

> >  В другой сборочной среде C1 тот же самый пакет <S,C,P> просто не
> >  существует, нету такого понятия (это крайний холистический взгляд
> >  на пакеты).
> Если исходники всех зависимостей и самого пакета одни и те же, то
> бинарный результат вполне предсказуем.

Исходники зависимостей тоже чем-то собирались, и в разном порядке.  Если
все исходники всех зависимостей пересобрать (с замещением) несклько раз
подряд самими же собою (это похоже на bootstrap), то тогда да, Ваша
модель данных похожа на правду.

Но мы имеем hahser, который не пересобирает все исходники всех
зависимостей по несколько раз, прежде чем собрать что-то новое.

Значит, мы имеем достаточно сложную модель данных: "постепенные
промежуточные переходы" из одного состояния в другое состояние.
Последовательность постепенных переходов "схлопнуть" нельзя.

> >  Далее, править исходники нельзя, потому что P это образ S.
> >  То есть, фиксируя исходники S и сборочную среду C, мы получаем
> >  понятие пакета <S,C,P>.  Всё остальное это не пакеты, а так вообще
> >  какие-то файлы левые в каталогах лежат, которые нужно удалить.
> Вот в том то и проблема, что сборочную среду как-то стремно
> фиксировать. Потом ничего менять нельзя. Так вот и бранч не обновишь
> из-за того, что там у всех пакетов в сборочной среде был какой-то там
> пакет, который всем нужен, вот его и не обновить никак...

Как установить идентичность пакета?  Что такое пакет?
Пакет, это что, %name-%version-%release.src.rpm?
Но нас интересуют не столькко исходники, сколько результат их сборки.
Мой ответ: пакет -- это, строго говоря, <S,C,P>.

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

> Может проще будет тогда представить с другой стороны: вот есть Gentoo.
> Там исходники какбы начало всего. Вот выложили вы исходники в testing
> и пересобрали мир. Если с исходниками все в порядке, то testing выйдет
> аккуратным без анметов и прочих неприятностей. Можно его тогда в

Вы описываете bootstrap -- типа, "всё пересобрать с нуля" из исходников.
На самом деле это слабая форма bootstrap'а.  Для сильного bootstrap'а
нужно всё пересобрать ещё раз (с полным замещением) и убедиться, что
результат получился идентичный.

Что касается Сизифа, то полная пересборка практически нереальна, и нужно
выдумывать модель данных с "постепенными переходами" и фиксацией
промежуточных изменений.

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

Я не против правки исходников (может быть, я слишком категорично и
притом неясно выразился).  Я за идентичность сборки.  Если исходники
меняются, то и пакет менятся; значит, это нужно отслеживать.

> То есть, пакет должен быть функцией от исходников - своих и зависимостей.
> Тругое дело, что кроме всего прочего средств для пересборки сизифа нет
> и testing'а тоже нет.

Вы оптимистично настроены насчёт "исходников зависимостей".  А ведь это
рекурсивный процесс.  "Исходники зависимостей" нужно для начала собрать.
А чтобы их для начала собрать, нужно сначала собрать ты-ты-ты и т.д.

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