[devel] rpm-macros-ubt
Anton Farygin
rider на basealt.ru
Вт Окт 31 14:01:40 MSK 2017
31.10.2017 13:53, Vladimir D. Seleznev пишет:
> On Tue, Oct 31, 2017 at 07:46:51AM +0300, Anton Farygin wrote:
>> 31.10.2017 00:04, Vladimir D. Seleznev пишет:
>>> On Mon, Oct 30, 2017 at 11:35:56PM +0300, Dmitry V. Levin wrote:
>>>> On Mon, Oct 30, 2017 at 09:16:55PM +0300, Anton Farygin wrote:
>>>>> 30.10.2017 18:30, Mikhail Efremov пишет:
>>>>>> On Mon, 30 Oct 2017 18:13:11 +0300 Anton Farygin wrote:
>>>>>>> 30.10.2017 17:39, Anton V. Boyarshinov пишет:
>>>>>>>> On Mon, 30 Oct 2017 15:34:20 +0300 Anton Farygin wrote:
>>>>>>>>
>>>>>>>>> С FTP я конечно махнул. Имелось в виду то, что в разных бранчах будут
>>>>>>>>> лежать сильно отличающиеся пакеты, которые при этом будут иметь
>>>>>>>>> одинаковое имя файла.
>>>>>>>> И что в этом такого уж плохого? Вообще, это открывает немало
>>>>>>>> возможностей, сейчас закрытых.
>>>>>>> А ты сможешь определить по скачанному файлу, для какого бранча он
>>>>>>> предназачен ?
>>>>>>>
>>>>>>> Без Linux/RPM ?
>>>>>> А что, сейчас это возможно? Откуда взялся пакет с релизом alt1?
>>>>>>
>>>>> С релизом alt1 - нет, невозможно. Но во всех репозиториях может быть
>>>>> только один идентичный (одинаковый) файл с таким релизом.
>>>>>
>>>>> а вот с релизом alt0.M80P.1 - да, возможно даже визуально определить.
>>>> Возможность по имени файла визуально определить, в какой бранч он был
>>>> собран, не кажется мне столь важной, особенно в перспективе, когда будет
>>>> много разных бранчей с более длинными именами и различными сроками жизни.
>>> С другой стороны, ничего не мешает к релизу собранного бинарного пакета
>>> добавлять appendix в виде .${!сизиф?имя_бранча}[.rb${номер_пересборки}],
>>> особенно если ченджлог будет дописываться. Тогда каждая новая сборка
>>> бинарного пакета в каждый бранч будет иметь уникальное имя, например,
>>> package-1.0.0-alt1.p9.rb2.x86_64.rpm.
>> И чем это будет отличаться от %ubt ?
> %ubt находится в исходном пакете, и при сборке бинарных пакетов с %ubt
> меняется не только суффик бранча, что принципиально. А в текущем
> предложении исходный пакет не изменяется, и никакая информация из него
> при сборке бинарных пакетов не искажается. Однако, основная мысль у меня
> была не сколько про указание бранча, сколько про итераций пересборки
> данного пакета для данного бранча, с добавлением в бинарный пакет всех
> ченджлогов с датами пересборки (и, если предусмотреть механизм, причиной
> пересборки). К сожалению, при сборке следующего релиза вся эта история
> потеряется...
Я ничего из этого не понял. Да, меняется %release, соответственным
образом меняется changelog.
Но - текущий формат changelog это всего-лишь устоявшееся правило,
зафиксированное скриптами проверки. Если эти скрипты будут каким-то
образом не считать за ошибку не полное совпадение release в записи
версии changelog, то естественно %ubt из changelog можно легко будет убрать.
> Но, опять-таки, было бы лучше, если бы по факту пересборки изменения
> вносились с исходный пакет, но я пока не представляю как это можно было
> бы аккуратно сделать.
Исходный пакет - это атавизм.
Подробная информация о списке рассылки Devel