On Fri, 6 Dec 2019, Vladimir D. Seleznev wrote:

> 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) воспроизвести сборку 
> > некоторых пакетов, которые там лежат. Т.е. например, в дистрибутив попали 
> > они в старом виде, а если нас просят для сертификации воспроизвести сборку 
> > и доказать, что получается такой результат, это сделать не получается.
> 
> О воспроизводимости сборки имеет смысл говорить только в том же
> сборочном окружении, в котором собирался пакет. Т.к. мы журналируем

Да, я говорил о воспроизводимости в другом смысле. Можно так сказать: 
актуальны ли сохранённые в репозитории пакеты или при их пересборке в 
текущем репозитории получится другой результат. (Если другой, то это может 
противоречить задумке авторов изменения макросов и других сборочных 
инструментов: они считают, что правильнее делать по-новому.) Говорю о 
помощи в улучшении текущего репозитория и всех пакетов, а не о раскопках с 
целью убедить, что в истории пакета нет обмана.

> Что касается сертифицикации, то, возможно, самым простым решением будет
> сразу после бранчевания делать пересборку всех тех пакетов, что пойдут
> на сертификацию, и после этого доказать (статистически)
> воспроизводимость уже этой сборки.
> 
> Про воспроизводимость сборки можно почитать тут [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 mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel