[devel] detect macro mismatches between old built packages and new ones? Re: hsh --query-repackage Re: ACL request for perl update to 5.30

Ivan Zakharyaschev imz на altlinux.org
Чт Дек 5 23:10:02 MSK 2019


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

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

(Я такие механизмы уже некоторое время назад обдумывал.)

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

-- 
Best regards,
Ivan


Подробная информация о списке рассылки Devel