[devel] Воспроизводимая сборка пакетов (Was: detect macro mismatches between old built packages and new ones? Re: hsh --query-repackage Re: ACL request for perl update to 5.30)
Vladimir D. Seleznev
vseleznv на altlinux.org
Пт Дек 6 22:27:02 MSK 2019
On Thu, Dec 05, 2019 at 11:10:02PM +0300, Ivan Zakharyaschev wrote:
> On Thu, 5 Dec 2019, Dmitry V. Levin wrote:
>
> > On Thu, Dec 05, 2019 at 05:57:17PM +0300, Sergey Bolshakov wrote:
> > > >>>>> "Ivan" == Ivan Zakharyaschev <imz-u2l5PoMzF/Vg9hUCZPvPmw на public.gmane.org> writes:
> > > [skipped]
> > >
> > > >> Есть и другое мнение, которое сводится примерно к тому, что
> > > >> опубликованное на ftp.a.o было бы хорошо содержать в виде, пригодном
> > > >> для простого hsh path/to/src.rpm
> > >
> > > > Мнение, конечно, разумное. Но можно предлагать использовать просто:
> > >
> > > > hsh --query-repackage path/to/src.rpm
> > > > Можно считать это способом по умолчанию. (Более вычислительно нагруженный,
> > > > зато так, как теперь в girar по умолчанию.)
> > >
> > > Дело не в ключах вызова hsh, по большому счёту.
> > > Сейчас в опубликованных src.rpm написано: собрано быть не может, simple as.
> > > Впору спросить себя -- зачем мы их вообще выкладываем.
> >
> > Хороший вопрос. Вероятно, для тестовой пересборки, она их использует.
> >
> > Кстати, в сборочнице используется hsh-rebuild --query-repackage.
> > Иначе бы тот пакет, о котором идёт речь, даже не собрался бы.
>
> Как тут в этом обсуждении говорили, как я понял, при пересборке этого
> пакета в нынешней среде Sisyphus получается какой-то не очень разумный
> результат. (Поправьте, если я неправильно понял.) Т.е. претензия даже не в
> том, что результат другой, но и что плохой. Стал плохим после того, как
> значение макроса изменилось.
>
> И вообще, это, конечно, не очень хорошая ситуация (даже если результат
> другой, а не плохой). Потому что получается что на текущем состоянии
> репозитория мы не можем (не важно с какой опцией hsh) воспроизвести сборку
> некоторых пакетов, которые там лежат. Т.е. например, в дистрибутив попали
> они в старом виде, а если нас просят для сертификации воспроизвести сборку
> и доказать, что получается такой результат, это сделать не получается.
О воспроизводимости сборки имеет смысл говорить только в том же
сборочном окружении, в котором собирался пакет. Т.к. мы журналируем
метаинформацию о сборочных заданиях в индексах исходных пакетов [1], из
которых мы можем вытащить информацию о том, в какой сборочном окружении
мы собирали пакет, и мы сохраняем состояния репозиториев для всех
собранных тасков [2], то мы можем легко воспроизвести сборочное
окружение и воспроизвести сборку. Другое дело, что сейчас не для всех
пакетов сборочный результат получается идентичным. У меня пока нет
статистики, но я думаю, что не вредно будет собирать такую статистику.
Т.е., организовать регулярную ассинхронную проверку, что результат
пересборки пакета в том же сборочном окружении, при котором он попал в
репозиторий, совпадает с тем, что лежит в репозитории.
Что касается сертифицикации, то, возможно, самым простым решением будет
сразу после бранчевания делать пересборку всех тех пакетов, что пойдут
на сертификацию, и после этого доказать (статистически)
воспроизводимость уже этой сборки.
Про воспроизводимость сборки можно почитать тут [3].
> Можно было бы добавить механизм автоматического отслеживания значений
> макросов, использованных при сборке пакета, так чтобы в случае изменения
> значения возникало нечто аналогичное unmets сейчас. Т.е. пакет, меняющий
> значение макроса, использованного для сборки других пакетов, нельзя
> закоммитить, не пересобрав все пакеты, на которые он может повлиять.
>
> (Я такие механизмы уже некоторое время назад обдумывал.)
>
> С одной стороны, больше труда при сборке пакетов с макросами, с другой
> стороны, мы приобретаем лучшую готовность к пересборке пакетов на текущем
> состоянии репозитория (по тем или иным причнам: пресборка ради
> сертификации; пересборка с патчем -- плохо, если неожиданно сборка с
> патчем начнёт приводить совсем не к тому виду пакета, к которому
> привыкли).
Ссылки:
[1] http://ftp.altlinux.org/pub/distributions/archive/sisyphus/index/src/
[2] http://ftp.altlinux.org/pub/distributions/archive/sisyphus/task/archive/
[3] https://reproducible-builds.org/
--
С уважением,
Владимир Селезнев
Подробная информация о списке рассылки Devel