[devel] rpm-macros-ubt

Vladimir D. Seleznev vseleznv на altlinux.org
Вт Окт 31 14:32:43 MSK 2017


On Tue, Oct 31, 2017 at 02:01:40PM +0300, Anton Farygin wrote:
> 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.

Возможно, мне стоит позже более формально это расписать, но тут я
отвечал, чем предложенная мной выше схема лучше, чем использовать %ubt.

> Но - текущий формат changelog это всего-лишь устоявшееся правило, 
> зафиксированное скриптами проверки. Если эти скрипты будут каким-то 
> образом не считать за ошибку не полное совпадение release в записи 
> версии changelog, то естественно %ubt из changelog можно легко будет убрать.
> 
> 
> > Но, опять-таки, было бы лучше, если бы по факту пересборки изменения
> > вносились с исходный пакет, но я пока не представляю как это можно было
> > бы аккуратно сделать.
> Исходный пакет - это атавизм.

Я имел в виду исходный пакетов в более широком смысле: gear для
пакетов, собранных из gear'а, и src.rpm для, соответственно, src.rpm.

-- 
   С уважением,
   Владимир Селезнев


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