From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Fri, 6 Dec 2019 23:45:25 +0300 (MSK) From: Ivan Zakharyaschev To: ALT Linux Team development discussions In-Reply-To: <20191206192702.GA545296@portlab> Message-ID: References: <20191205130115.GA24572@dad.imath.kiev.ua> <20191205134918.GA26127@dad.imath.kiev.ua> <20191205141807.GB26127@dad.imath.kiev.ua> <20191205184628.GD13107@altlinux.org> <20191206192702.GA545296@portlab> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="1807885841-18263416-1575665125=:28829" Subject: Re: [devel] =?koi8-r?b?98/T0NLPydrXz8TJzcHRINPCz9LLwSDQwcvF1M/XIChX?= =?koi8-r?b?YXM6IGRldGVjdCBtYWNybyBtaXNtYXRjaGVzIGJldHdlZW4gb2xkIGJ1aWx0?= =?koi8-r?b?IHBhY2thZ2VzIGFuZCBuZXcgb25lcz8gUmU6IGhzaCAtLXF1ZXJ5LXJlcGFj?= =?koi8-r?b?a2FnZSBSZTogQUNMIHJlcXVlc3QgZm9yIHBlcmwgdXBkYXRlIHRvIDUuMzAp?= 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: Fri, 06 Dec 2019 20:45:25 -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-18263416-1575665125=:28829 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8BIT 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 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 --1807885841-18263416-1575665125=:28829--