Re: [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>]

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

On Thu, 5 Dec 2019, Anton Farygin wrote:

> On 05.12.2019 23:23, Ivan Zakharyaschev wrote:
> > On Thu, 5 Dec 2019, Anton Farygin wrote:
> >
> > > On 05.12.2019 23:10, Ivan Zakharyaschev wrote:
> > > > Можно было бы добавить механизм автоматического отслеживания значений
> > > > макросов, использованных при сборке пакета, так чтобы в случае изменения
> > > > значения возникало нечто аналогичное unmets сейчас. Т.е. пакет, меняющий
> > > > значение макроса, использованного для сборки других пакетов, нельзя
> > > > закоммитить, не пересобрав все пакеты, на которые он может повлиять.
> > > Зачем отслеживать макросы, если у нас уже отслеживаются результаты
> > > пересборок
> > > ? Достаточно сравнение пакетов сделать из предупреждения ошибкой.
> > Это тоже ценный источник информации, согласен.
> >
> > Но в текущей ситуации есть такое но:
> >
> > Сравнение пакетов делается в beehive, асинхронно после того, как
> > "виновник" с другим значением макроса уже попал в репозиторий.
> >
> > Сделать это ошибкой, которая бы помешала заданию успешно завершится, не
> > получится.
> >
> > А довольно дёшево можно сравнить значения макросов и бустро зарубить
> > задание. Примерно так же быстро, как сейчас обнаруживаются unmets. (Но
> > может быть довольно много сообщений об изменениях, которые реально не
> > отражаются на результате сборки. Трудно заранее оценить, много ли будет
> > таких не очень удобных "ложных" срабатываний.)
> 
> Можно придумать сотни способов слома чужих пакетов без использования макросов.
> Макросы это не показатель.

В целом я согласен.

Думал о них в первую, как о ключевых рычагах влияния на другие пакеты.

Например, повлиять на получившийся srpm можно главным образом через 
макросы. (Остальные инструменты влияют на бинарные пакеты.)

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

-- 
Best regards,
Ivan