[devel] rebuild without bumping release

[devel] rebuild without bumping release

[Alexey Tourbin]

Мужчины, оказывается у вас теперь можно пересобирать пакеты без
увеличения релиса.  Файлы %{Name}-%{Version}-%{Release}.%{Arch}.rpm
в репозитории переписываются поверх старых, а apt будет обновлять
их по изменившемуся %{BuildTime}.  В связи с этим несколько технических
замечаний.

== Перезапись .src.rpm ==

При пересборке из /gears будет замещен .src.rpm пакет
https://bugzilla.altlinux.org/show_bug.cgi?id=27840#c16
тогда как почти всегда этого можно не делать.
В частности, если у .src.rpm пакета не изменились запакованные файлы
и зависимости, то этого точно можно не делать (это похоже на критерий
"extensional equality", который советует делать noarch пакеты).

Репозиторий src.rpm пакетов не бесполезен, на нем можно проверять
сборочные зависимости (почти так же, как apt-cache unmet проверят
установочные зависимости).  Строгая проверка, которая не дает ложных
срабатываний, возможна только для той архитектуры, для которой .src.rpm
файлы отбираются в files/SRPMS; по-моему сейчас это i586.  Вероятно,
есть смысл отбирать пакеты в files/SRPMS из x86_64, поскольку именно она
давно уже стала основной архитектурой.

== Перезапись .noarch.rpm ==

Пересборка без увеличения релиса удобна в случае пересборки клиентов
с новыми версиями библиотек; при этом noarch-подпакеты, такие как foo-doc,
должны остаться без изменений; их тоже можно было бы не замещать.
Но теперь они получат зависимости с disttag+task, и поэтому критерий
extensional equality к ним не применим (пересобранные пакеты всегда
будут отличаться из-за таска).  Возможно, стоило бы ослабить межпакетные
зависимости при пересечении границы arch/noarch: вместо EVR:disttag+task
требовать только EVR:disttag.  Это дало бы возможность не переписывать
noarch-пакеты.

Но ведь noarch-пакетами все не ограничивается.  Так, при пересборке
библиотеки по идее должен измениться только подпакет libfoo, а libfoo-devel
должен остаться прежним.  Хорошо бы не переписывать и libfoo-devel.
Сделать это, к сожалению, сложно.  Я продумывал схему, как передать в
rpmbuild информацию об уже имеющихся собранных подпакетах.  Тогда
в конце сборки rpmbuild сможет решить, какие подпакеты экзистенционально
равны, и скорректировать зависимости у некоторых подпакетов, чтобы
исключить переписывание/обновление.  Но это не работает как следует,
потому что у зависимостей есть направление: пакет libfoo-devel требует
libfoo.  Если в libfoo-devel зашита строгая зависимость на libfoo, то не
обновлять его нельзя.

Почему не удается придумать хорошей схемы с частичным переписыванием
подпакетов?  Может, это очевидно, но до меня почему-то не сразу дошло.
Строгие зависимости с EVR:disttag+task направлены на то, чтобы запретить
совмещение пакетов из разных сборок.  А частичное переписывание как раз
направлено на совмещение пакетов из разных сборок.  Это не просто
разные, а противоположные цели.

== Пропатчивание индексов ==

Переписывание *.rpm пакетов поверх старых усложняет генерацию нового
pkglist.classic файла на основе старого pkglist.classic файла (это еще
как следует не реализовано).  Если исходить из того, что сборочная
система не переписывает *.rpm пакеты, то перекомпоновка записей в
pkglist.classic реализуется легко: пусть имеется предыдущее состояние
pkglist.classic и новое состояние RPMS.classic/.  Тогда все записи из
pkglist.classic, для которых в RPMS.classic/ есть пакет, кочуют в новый
pkglist.classic (совпадения по имени .rpm файла достаточно).  

Теперь же совпадения по имени .rpm файла становится недостаточно.
Причем чтобы схема перекомпоновки работала быстро, нужно ограничиваться
только stat-информацией (читать каждый .rpm пакет - гиблое дело).
На практике для идентификации пакетов st_size+st_mtime работают достаточно
хорошо.  Тогда для сравнения записей и пакетов нужно хранить в записи
дополнительный таг, CRPMTAG_FILEMTIME (а CRPMTAG_FILESIZE уже хранится).
Поскольку там уже хранится и RPMTAG_BUILDTIME, то можно попытаться
отождествить FILEMTIME и BUILDTIME.  Для этого придется выставлять
st_mtime в BUILDTIME.  Но может это и не очень хорошо, поскольку
st_mtime может меняться по уважительной причине (из-за подписывания
пакета).

Вообще, чтобы перекомпоновка работала как следует, нужно держать две
версии записей: более полную версию в pkglist.classic+bloat и обычную
версию для пользователя pkglist.classic.  В pkglist.classic+bloat
у каждой записи будет полный список файлов, а в pkglist.classic -
урезанный, направленный на удовлетворение файловых зависимостей.
Поэтому обычный pkglist.classic использовать для перекомпоновки нельзя.
Потому что список требуемых файлов у каждой записи зависит от других
записей.  Так что новый genpkglist должен концептуально работать в два
прохода: сначала перекомпоновать pkglist.classic+bloat, а потом отжать
из него pkglist.classic.  При такой схеме хранить таг CRPMTAG_FILEMTIME
можно только в pkglist.classic+bloat.

Индекс pkglist.classic+bloat и псевдорепозиторий classic+bloat не
бесполезны, у них просматривается несколько применений:

- сборочная система в любом случае генерирует bloat-репозиторий,
  когда пакетов в таске больше одного;
- аналогично при сборке нескольких пакетов в хешере иногда возникают
  неудовлетворенные файловые зависимости; для обхода этой проблемы можно
  вручную скопировать пакет из репозитория в RPMS.hasher, но это тяжело
  автоматизировать; вместо этого можно будет настроить хешер на
  classic+bloat;
- генерация contents_index;
- отслеживание файловых конфликтов (об этом - в другой раз).

Re: [devel] rebuild without bumping release

[Dmitry V. Levin]

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

On Fri, Mar 29, 2019 at 01:43:48PM +0300, Alexey Tourbin wrote:
> Мужчины, оказывается у вас теперь можно пересобирать пакеты без
> увеличения релиса.  Файлы %{Name}-%{Version}-%{Release}.%{Arch}.rpm
> в репозитории переписываются поверх старых, а apt будет обновлять
> их по изменившемуся %{BuildTime}.  В связи с этим несколько технических
> замечаний.
> 
> == Перезапись .src.rpm ==
> 
> При пересборке из /gears будет замещен .src.rpm пакет
> https://bugzilla.altlinux.org/show_bug.cgi?id=27840#c16
> тогда как почти всегда этого можно не делать.
> В частности, если у .src.rpm пакета не изменились запакованные файлы
> и зависимости, то этого точно можно не делать (это похоже на критерий
> "extensional equality", который советует делать noarch пакеты).

Пересобирая пакет без изменения исходного кода, мы вправе ожидать, что
получившийся новый .src.rpm не изменится существенным образом.  Если
у .src.rpm, собранного из /gears, не изменились запакованные файлы
и зависимости, то действительно можно сэкономить и оставить прежний
.src.rpm.

> Репозиторий src.rpm пакетов не бесполезен, на нем можно проверять
> сборочные зависимости (почти так же, как apt-cache unmet проверят
> установочные зависимости).  Строгая проверка, которая не дает ложных
> срабатываний, возможна только для той архитектуры, для которой .src.rpm
> файлы отбираются в files/SRPMS; по-моему сейчас это i586.  Вероятно,
> есть смысл отбирать пакеты в files/SRPMS из x86_64, поскольку именно она
> давно уже стала основной архитектурой.

Да, раньше это была архитектура i586, но с некоторых пор в прошлом году
мы стали брать пакеты в noarch и SRPMS из результатов сборки для x86_64.

> == Перезапись .noarch.rpm ==
> 
> Пересборка без увеличения релиса удобна в случае пересборки клиентов
> с новыми версиями библиотек; при этом noarch-подпакеты, такие как foo-doc,
> должны остаться без изменений; их тоже можно было бы не замещать.
> Но теперь они получат зависимости с disttag+task, и поэтому критерий
> extensional equality к ним не применим (пересобранные пакеты всегда
> будут отличаться из-за таска).  Возможно, стоило бы ослабить межпакетные
> зависимости при пересечении границы arch/noarch: вместо EVR:disttag+task
> требовать только EVR:disttag.  Это дало бы возможность не переписывать
> noarch-пакеты.
> 
> Но ведь noarch-пакетами все не ограничивается.  Так, при пересборке
> библиотеки по идее должен измениться только подпакет libfoo, а libfoo-devel
> должен остаться прежним.  Хорошо бы не переписывать и libfoo-devel.
> Сделать это, к сожалению, сложно.  Я продумывал схему, как передать в
> rpmbuild информацию об уже имеющихся собранных подпакетах.  Тогда
> в конце сборки rpmbuild сможет решить, какие подпакеты экзистенционально
> равны, и скорректировать зависимости у некоторых подпакетов, чтобы
> исключить переписывание/обновление.  Но это не работает как следует,
> потому что у зависимостей есть направление: пакет libfoo-devel требует
> libfoo.  Если в libfoo-devel зашита строгая зависимость на libfoo, то не
> обновлять его нельзя.
> 
> Почему не удается придумать хорошей схемы с частичным переписыванием
> подпакетов?  Может, это очевидно, но до меня почему-то не сразу дошло.
> Строгие зависимости с EVR:disttag+task направлены на то, чтобы запретить
> совмещение пакетов из разных сборок.  А частичное переписывание как раз
> направлено на совмещение пакетов из разных сборок.  Это не просто
> разные, а противоположные цели.

Мы исходили из того, что если раньше зависимости между подпакетами были
жёсткими, то введение ещё одной степени свободы в дополнение к EVR не
должно сделать их менее жёсткими.  Автоматически выяснять, нужна ли такая
жёсткость в зависимостях между подпакетами, мы в общем случае не умеем,
поэтому пусть они остаются жесткими.

> == Пропатчивание индексов ==
> 
> Переписывание *.rpm пакетов поверх старых усложняет генерацию нового
> pkglist.classic файла на основе старого pkglist.classic файла (это еще
> как следует не реализовано).  Если исходить из того, что сборочная
> система не переписывает *.rpm пакеты, то перекомпоновка записей в
> pkglist.classic реализуется легко: пусть имеется предыдущее состояние
> pkglist.classic и новое состояние RPMS.classic/.  Тогда все записи из
> pkglist.classic, для которых в RPMS.classic/ есть пакет, кочуют в новый
> pkglist.classic (совпадения по имени .rpm файла достаточно).  
> 
> Теперь же совпадения по имени .rpm файла становится недостаточно.
> Причем чтобы схема перекомпоновки работала быстро, нужно ограничиваться
> только stat-информацией (читать каждый .rpm пакет - гиблое дело).
> На практике для идентификации пакетов st_size+st_mtime работают достаточно
> хорошо.  Тогда для сравнения записей и пакетов нужно хранить в записи
> дополнительный таг, CRPMTAG_FILEMTIME (а CRPMTAG_FILESIZE уже хранится).
> Поскольку там уже хранится и RPMTAG_BUILDTIME, то можно попытаться
> отождествить FILEMTIME и BUILDTIME.  Для этого придется выставлять
> st_mtime в BUILDTIME.  Но может это и не очень хорошо, поскольку
> st_mtime может меняться по уважительной причине (из-за подписывания
> пакета).

У меня была идея определять, какие записи следует удалить из pkglist,
а какие добавить, на основе плана обновления, поскольку в файлах add-bin
и rm-bin уже достаточно информации.  Может быть, это даже немного проще,
чем добавлять новый CRPMTAG в pkglist.

> Вообще, чтобы перекомпоновка работала как следует, нужно держать две
> версии записей: более полную версию в pkglist.classic+bloat и обычную
> версию для пользователя pkglist.classic.  В pkglist.classic+bloat
> у каждой записи будет полный список файлов, а в pkglist.classic -
> урезанный, направленный на удовлетворение файловых зависимостей.
> Поэтому обычный pkglist.classic использовать для перекомпоновки нельзя.
> Потому что список требуемых файлов у каждой записи зависит от других
> записей.  Так что новый genpkglist должен концептуально работать в два
> прохода: сначала перекомпоновать pkglist.classic+bloat, а потом отжать
> из него pkglist.classic.  При такой схеме хранить таг CRPMTAG_FILEMTIME
> можно только в pkglist.classic+bloat.
> 
> Индекс pkglist.classic+bloat и псевдорепозиторий classic+bloat не
> бесполезны, у них просматривается несколько применений:
> 
> - сборочная система в любом случае генерирует bloat-репозиторий,
>   когда пакетов в таске больше одного;
> - аналогично при сборке нескольких пакетов в хешере иногда возникают
>   неудовлетворенные файловые зависимости; для обхода этой проблемы можно
>   вручную скопировать пакет из репозитория в RPMS.hasher, но это тяжело
>   автоматизировать; вместо этого можно будет настроить хешер на
>   classic+bloat;
> - генерация contents_index;
> - отслеживание файловых конфликтов (об этом - в другой раз).

Да, пожалуй что так.


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]