On Wed, Feb 01, 2012 at 09:47:47PM +0400, Alexey Tourbin wrote:
> On Sat, Jan 28, 2012 at 04:19:39AM +0400, Dmitry V. Levin wrote:
> > 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
> > много лет назад, так что можно полагать, что у всех наших пользователей
> > она уже есть.
> 
> Результат сборки пакетов не должен зависеть от модельного времени t,
> а должен зависеть только от ингредиентов, которые напрямую влияют на
> результат сборки.  Таких ингредиентов два: B(S,C)->P, где S - исходный
> код пакета, C - содержимое сборочного чрута.

Время t тоже напрямую (через такие интерфейсы как gettimeofday(2)) может
влиять на результат сборки.  Но суть не в этом.

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

Речь идет вообще не о зависимостях, а об обновлении собранных пакетах
как таковых.
Если один и тот же исходный пакет был собран последовательно на разных
состояниях одного и того же репозитория, и даже если обе сборки вполне
совместимы с каждым из этих состояний репозитория, то это не значит, что
эти сборки идентичны.  Поскольку чруты у них различаются, они сами
тоже различаются.  Для rpm они различимы уже много лет, в нем была
реализована возможность различать пакеты с одинаковыми NSVR по
SHA1HEADER и упорядочивать их по BUILDTIME.  А для apt они эквивалентны,
и характеристика B нужна для того, чтобы их различать и упорядочить.

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


-- 
ldv