From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Thu, 5 Dec 2019 23:39:09 +0300 (MSK) From: Ivan Zakharyaschev To: ALT Linux Team development discussions In-Reply-To: <58669b78-7cad-85ed-1b34-0daa82850343@basealt.ru> Message-ID: References: <20191205112355.GA15256@dad.imath.kiev.ua> <20191205130115.GA24572@dad.imath.kiev.ua> <20191205134918.GA26127@dad.imath.kiev.ua> <20191205141807.GB26127@dad.imath.kiev.ua> <20191205184628.GD13107@altlinux.org> <0b363aa9-ae1a-24e6-b31d-605a8ca398e5@basealt.ru> <58669b78-7cad-85ed-1b34-0daa82850343@basealt.ru> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="1807885841-539683837-1575578349=:28829" Subject: 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 X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 20:39:11 -0000 Archived-At: List-Archive: List-Post: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1807885841-539683837-1575578349=:28829 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8BIT 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 --1807885841-539683837-1575578349=:28829--