[devel] Обертка #if / #endif в spec для бранчей

[devel] Обертка #if / #endif в spec для бранчей

[Evgeniy Korneechev]

Всем доброго!
А в нашем RPM есть нечто подобное сабж?

-- 
PS Просьба держать в копии всех получателей, нажимая кнопку "Ответить всем".

WBR, Korneechev Evgeniy
BaseALT/ALTLinux Team

Re: [devel] Обертка #if / #endif в spec для бранчей

[Vitaly Lipatov]

Evgeniy Korneechev писал 17.11.20 13:02:
> Всем доброго!
> А в нашем RPM есть нечто подобное сабж?

Я делаю так в wine:

# rpm-build-info gives _distro_version
%if %_vendor == "alt" && (%_distro_version == "p9" || %_distro_version 
== "Sisyphus")
%def_with vulkan
...
%endif
...
BuildRequires(pre): rpm-build-intro >= 2.1.14

-- 
С уважением,
Виталий Липатов,
ALT Linux Team

Re: [devel] Обертка #if / #endif в spec для бранчей

[Sergey V Turchin]

On Tuesday, 17 November 2020 16:11:19 MSK Vitaly Lipatov wrote:
> Evgeniy Korneechev писал 17.11.20 13:02:
> > Всем доброго!
> > А в нашем RPM есть нечто подобное сабж?
> 
> Я делаю так в wine:
> 
> # rpm-build-info gives _distro_version
> %if %_vendor == "alt" && (%_distro_version == "p9" || %_distro_version
> == "Sisyphus")
> %def_with vulkan
> ...
> %endif
> ...
> BuildRequires(pre): rpm-build-intro >= 2.1.14
Я делаю
%if_ver_gteq %ubt_id M90
%def_enable vulkan
...
%endif
BuildRequires(pre): rpm-build-ubt
Так же в spec добавить нужные макросы из http://bugs.altlinux.org/6010 .
Ещё подгадил админ сборочницы, поэтому придётся в начало spec добавить 2 
строки:
%{expand: %(sed 's,^%%,%%global ,' /usr/lib/rpm/macros.d/ubt)}
%define ubt_id %__ubt_branch_id

-- 
Regards, Sergey.

[devel] [JT] про команду, %ubt, -xalt и прочее разное

[Michael Shigorin]

On Tue, Nov 17, 2020 at 04:29:58PM +0300, Sergey V Turchin wrote:
> Ещё подгадил админ сборочницы

Ну вообще-то сперва кое-кто единолично нагадил %ubt, на вычищение
которого (и борьбу с непредвиденными кое-кем последствиями) ушла
масса времени и сил минимум нескольких человек.

Понятно, что игнорирование запросов даёт и такие результаты,
но всё-таки _команда_ -- это не "ясно, тогда пофиг на вас",
а и когда трудно -- то сообща, а не у кого насест выше.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] [JT] про команду, %ubt, -xalt и прочее разное

[Sergey V Turchin]

On Tuesday, 17 November 2020 21:56:18 MSK Michael Shigorin wrote:
> On Tue, Nov 17, 2020 at 04:29:58PM +0300, Sergey V Turchin wrote:
> > Ещё подгадил админ сборочницы
> 
> Ну вообще-то сперва кое-кто единолично нагадил %ubt,
Тут, понимаешь ли, лишь буквы похожие.
Это совсем другая фича, которая не имеет ничего общего с тем, о чем ты и 
используется мной до сих пор, т.к. аналог я 1-й раз вижу у Виталия, но у меня 
покруче, т.к. позволяет не только ==, но и <, <, >= и т.д.

> на вычищение
> которого (и борьбу с непредвиденными кое-кем последствиями) ушла
> масса времени и сил минимум нескольких человек.
Это искусственно созданная(не мной) проблема и цветочки по сравнению с 
disttag.

> Понятно, что игнорирование запросов даёт и такие результаты,
> но всё-таки _команда_ -- это не "ясно, тогда пофиг на вас",
> а и когда трудно -- то сообща, а не у кого насест выше.
Мысль совсем упорхала, хоть я и понимаю, о чём ты. ;-)

-- 
Regards, Sergey.

Re: [devel] [JT] про команду, %ubt, -xalt и прочее разное

[Mikhail Novosyolov]

18.11.2020 10:41, Sergey V Turchin пишет:
> On Tuesday, 17 November 2020 21:56:18 MSK Michael Shigorin wrote:
>> On Tue, Nov 17, 2020 at 04:29:58PM +0300, Sergey V Turchin wrote:
>>> Ещё подгадил админ сборочницы
>> Ну вообще-то сперва кое-кто единолично нагадил %ubt,
> Тут, понимаешь ли, лишь буквы похожие.
> Это совсем другая фича, которая не имеет ничего общего с тем, о чем ты и 
> используется мной до сих пор, т.к. аналог я 1-й раз вижу у Виталия, но у меня 
> покруче, т.к. позволяет не только ==, но и <, <, >= и т.д.
>
>> на вычищение
>> которого (и борьбу с непредвиденными кое-кем последствиями) ушла
>> масса времени и сил минимум нескольких человек.
> Это искусственно созданная(не мной) проблема и цветочки по сравнению с 
> disttag.
>
А нельзя просто гарантированно пересобирать пакеты при копировании из сизифа в бранч, чтобы в %disstag появлялось p9, а потом на него смотреть?

Re: [devel] [JT] про команду, %ubt, -xalt и прочее разное

[Vitaly Lipatov]

Sergey V Turchin писал 18.11.20 10:41:
> On Tuesday, 17 November 2020 21:56:18 MSK Michael Shigorin wrote:
>> On Tue, Nov 17, 2020 at 04:29:58PM +0300, Sergey V Turchin wrote:
>> > Ещё подгадил админ сборочницы
>> 
>> Ну вообще-то сперва кое-кто единолично нагадил %ubt,
> Тут, понимаешь ли, лишь буквы похожие.
> Это совсем другая фича, которая не имеет ничего общего с тем, о чем ты 
> и
> используется мной до сих пор, т.к. аналог я 1-й раз вижу у Виталия, но 
> у меня
> покруче, т.к. позволяет не только ==, но и <, <, >= и т.д.
Если что, я просто за тем нездоровым ажиотажем забыл, что такая 
возможность есть в ubt, и так как давно мечтал чем-то подобным 
пользоваться (чтобы отойти от бэкпортирования с изменением спека под 
бранч), недавно добавил свой вариант.

-- 
С уважением,
Виталий Липатов,
ALT Linux Team

Re: [devel] [JT] про команду, %ubt, -xalt и прочее разное

[Andrey Savchenko]

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

On Wed, 18 Nov 2020 23:19:51 +0300 Mikhail Novosyolov wrote:
> 18.11.2020 10:41, Sergey V Turchin пишет:
> > On Tuesday, 17 November 2020 21:56:18 MSK Michael Shigorin wrote:
> >> On Tue, Nov 17, 2020 at 04:29:58PM +0300, Sergey V Turchin wrote:
> >>> Ещё подгадил админ сборочницы
> >> Ну вообще-то сперва кое-кто единолично нагадил %ubt,
> > Тут, понимаешь ли, лишь буквы похожие.
> > Это совсем другая фича, которая не имеет ничего общего с тем, о чем ты и 
> > используется мной до сих пор, т.к. аналог я 1-й раз вижу у Виталия, но у меня 
> > покруче, т.к. позволяет не только ==, но и <, <, >= и т.д.
> >
> >> на вычищение
> >> которого (и борьбу с непредвиденными кое-кем последствиями) ушла
> >> масса времени и сил минимум нескольких человек.
> > Это искусственно созданная(не мной) проблема и цветочки по сравнению с 
> > disttag.
> >
> А нельзя просто гарантированно пересобирать пакеты при копировании из сизифа в бранч, чтобы в %disstag появлялось p9, а потом на него смотреть?

Сейчас так и делается, насколько я знаю. Но это требует повторять
весь bootstrap, если таковой есть, что печально и приводит к пустой
трате ресурсов, в первую очередь человеческих.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] [JT] про команду, %ubt, -xalt и прочее разное

[Mikhail Novosyolov]

19.11.2020 00:57, Andrey Savchenko пишет:

> On Wed, 18 Nov 2020 23:19:51 +0300 Mikhail Novosyolov wrote:
>> 18.11.2020 10:41, Sergey V Turchin пишет:
>>> On Tuesday, 17 November 2020 21:56:18 MSK Michael Shigorin wrote:
>>>> On Tue, Nov 17, 2020 at 04:29:58PM +0300, Sergey V Turchin wrote:
>>>>> Ещё подгадил админ сборочницы
>>>> Ну вообще-то сперва кое-кто единолично нагадил %ubt,
>>> Тут, понимаешь ли, лишь буквы похожие.
>>> Это совсем другая фича, которая не имеет ничего общего с тем, о чем ты и 
>>> используется мной до сих пор, т.к. аналог я 1-й раз вижу у Виталия, но у меня 
>>> покруче, т.к. позволяет не только ==, но и <, <, >= и т.д.
>>>
>>>> на вычищение
>>>> которого (и борьбу с непредвиденными кое-кем последствиями) ушла
>>>> масса времени и сил минимум нескольких человек.
>>> Это искусственно созданная(не мной) проблема и цветочки по сравнению с 
>>> disttag.
>>>
>> А нельзя просто гарантированно пересобирать пакеты при копировании из сизифа в бранч, чтобы в %disstag появлялось p9, а потом на него смотреть?
> Сейчас так и делается, насколько я знаю. Но это требует повторять
> весь bootstrap, если таковой есть, что печально и приводит к пустой
> трате ресурсов, в первую очередь человеческих.

Можете привести примеры, где требуется повторить bootstrap?

Обычно  достаточно просто пересобрать пакеты в уже отбутстрапленном окружении.

Может прийтись заново сделать бутстрап, если, например, в целевом бранче версия libstdc++ ниже, чем та, с которой были собраны копируемые бинарные пакеты, но речь идет про момент бранчевание - первой сборки бранча, когда версии всех пакетов одинаковые.

Re: [devel] [JT] про команду, %ubt, -xalt и прочее разное

[Sergey V Turchin]

On Thursday, 19 November 2020 00:26:31 MSK Vitaly Lipatov wrote:
> Sergey V Turchin писал 18.11.20 10:41:
> > On Tuesday, 17 November 2020 21:56:18 MSK Michael Shigorin wrote:
> >> On Tue, Nov 17, 2020 at 04:29:58PM +0300, Sergey V Turchin wrote:
> >> > Ещё подгадил админ сборочницы
> >> 
> >> Ну вообще-то сперва кое-кто единолично нагадил %ubt,
> > 
> > Тут, понимаешь ли, лишь буквы похожие.
> > Это совсем другая фича, которая не имеет ничего общего с тем, о чем ты
> > и
> > используется мной до сих пор, т.к. аналог я 1-й раз вижу у Виталия, но
> > у меня
> > покруче, т.к. позволяет не только ==, но и <, <, >= и т.д.
> 
> Если что, я просто за тем нездоровым ажиотажем забыл, что такая
> возможность есть в ubt, и так как давно мечтал чем-то подобным
> пользоваться (чтобы отойти от бэкпортирования с изменением спека под
> бранч), недавно добавил свой вариант.
Ну, вот, мой без костыля теперь не получается использовать, т.к. сборочница 
предательски и абсолютно незаслуженно убивает значение макроса %ubt_id.

Если ты у себя сделаешь значения _distro_version пригодные для сравнения, то 
сможешь пользоваться макросами сравнения версий http://bugs.altlinux.org/6010 
.

-- 
Regards, Sergey.

Re: [devel] [JT] про команду, %ubt, -xalt и прочее разное

[Anton V. Boyarshinov]

В Wed, 18 Nov 2020 23:19:51 +0300
Mikhail Novosyolov <mikhailnov@altlinux.org> пишет:

> А нельзя просто гарантированно пересобирать пакеты при копировании из сизифа в бранч, чтобы в %disstag появлялось p9, а потом на него смотреть?

Вообще говоря, мы пытаемся решить скорее обратную задачу -- чтоб если
пакет из Сизифа при сборке в бранч существенно не изменился, то чтоб в
бранч попадал именно пакет из Сизифа, а не пересобранный.

Re: [devel] [JT] про команду, %ubt, -xalt и прочее разное

[Andrey Savchenko]

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

On Thu, 19 Nov 2020 10:08:42 +0300 Mikhail Novosyolov wrote:
> 19.11.2020 00:57, Andrey Savchenko пишет:
> 
> > On Wed, 18 Nov 2020 23:19:51 +0300 Mikhail Novosyolov wrote:
> >> 18.11.2020 10:41, Sergey V Turchin пишет:
> >>> On Tuesday, 17 November 2020 21:56:18 MSK Michael Shigorin wrote:
> >>>> On Tue, Nov 17, 2020 at 04:29:58PM +0300, Sergey V Turchin wrote:
> >>>>> Ещё подгадил админ сборочницы
> >>>> Ну вообще-то сперва кое-кто единолично нагадил %ubt,
> >>> Тут, понимаешь ли, лишь буквы похожие.
> >>> Это совсем другая фича, которая не имеет ничего общего с тем, о чем ты и 
> >>> используется мной до сих пор, т.к. аналог я 1-й раз вижу у Виталия, но у меня 
> >>> покруче, т.к. позволяет не только ==, но и <, <, >= и т.д.
> >>>
> >>>> на вычищение
> >>>> которого (и борьбу с непредвиденными кое-кем последствиями) ушла
> >>>> масса времени и сил минимум нескольких человек.
> >>> Это искусственно созданная(не мной) проблема и цветочки по сравнению с 
> >>> disttag.
> >>>
> >> А нельзя просто гарантированно пересобирать пакеты при копировании из сизифа в бранч, чтобы в %disstag появлялось p9, а потом на него смотреть?
> > Сейчас так и делается, насколько я знаю. Но это требует повторять
> > весь bootstrap, если таковой есть, что печально и приводит к пустой
> > трате ресурсов, в первую очередь человеческих.
> 
> Можете привести примеры, где требуется повторить bootstrap?
> 
> Обычно  достаточно просто пересобрать пакеты в уже отбутстрапленном окружении.

Есть бранч, где был сделан бутстрап. Есть бранч, где старая версия.
Как Вы получите в старом бранче уже отбустрапленное окружение, если
нет возможности скопировать бинарные пакеты? Только повторение
бутстрапа. На Эльбрусовой сборочнице именно так весь тулчейн
и переносится. Благо, там есть бинарное копирование.

> Может прийтись заново сделать бутстрап, если, например, в
> целевом бранче версия libstdc++ ниже, чем та, с которой были
> собраны копируемые бинарные пакеты, но речь идет про момент
> бранчевание - первой сборки бранча, когда версии всех пакетов
> одинаковые.

Бранчевание — не одномоментный процесс. До заморозки много воды
утечёт, да и после CVE никто не отменял.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] [JT] про команду, %ubt, -xalt и прочее разное

[Mikhail Novosyolov]

19.11.2020 11:33, Anton V. Boyarshinov пишет:
> В Wed, 18 Nov 2020 23:19:51 +0300
> Mikhail Novosyolov <mikhailnov@altlinux.org> пишет:
>
>> А нельзя просто гарантированно пересобирать пакеты при копировании из сизифа в бранч, чтобы в %disstag появлялось p9, а потом на него смотреть?
> Вообще говоря, мы пытаемся решить скорее обратную задачу -- чтоб если
> пакет из Сизифа при сборке в бранч существенно не изменился, то чтоб в
> бранч попадал именно пакет из Сизифа, а не пересобранный.
А зачем? И вы уверены, что set-versions настолько крут, что для гарантирования целостности ABI не стоит пересобирать пакет?

Re: [devel] [JT] про команду, %ubt, -xalt и прочее разное

[Mikhail Novosyolov]

19.11.2020 13:40, Andrey Savchenko пишет:
> On Thu, 19 Nov 2020 10:08:42 +0300 Mikhail Novosyolov wrote:
>> 19.11.2020 00:57, Andrey Savchenko пишет:
>>
>>> On Wed, 18 Nov 2020 23:19:51 +0300 Mikhail Novosyolov wrote:
>>>> 18.11.2020 10:41, Sergey V Turchin пишет:
>>>>> On Tuesday, 17 November 2020 21:56:18 MSK Michael Shigorin wrote:
>>>>>> On Tue, Nov 17, 2020 at 04:29:58PM +0300, Sergey V Turchin wrote:
>>>>>>> Ещё подгадил админ сборочницы
>>>>>> Ну вообще-то сперва кое-кто единолично нагадил %ubt,
>>>>> Тут, понимаешь ли, лишь буквы похожие.
>>>>> Это совсем другая фича, которая не имеет ничего общего с тем, о чем ты и 
>>>>> используется мной до сих пор, т.к. аналог я 1-й раз вижу у Виталия, но у меня 
>>>>> покруче, т.к. позволяет не только ==, но и <, <, >= и т.д.
>>>>>
>>>>>> на вычищение
>>>>>> которого (и борьбу с непредвиденными кое-кем последствиями) ушла
>>>>>> масса времени и сил минимум нескольких человек.
>>>>> Это искусственно созданная(не мной) проблема и цветочки по сравнению с 
>>>>> disttag.
>>>>>
>>>> А нельзя просто гарантированно пересобирать пакеты при копировании из сизифа в бранч, чтобы в %disstag появлялось p9, а потом на него смотреть?
>>> Сейчас так и делается, насколько я знаю. Но это требует повторять
>>> весь bootstrap, если таковой есть, что печально и приводит к пустой
>>> трате ресурсов, в первую очередь человеческих.
>> Можете привести примеры, где требуется повторить bootstrap?
>>
>> Обычно  достаточно просто пересобрать пакеты в уже отбутстрапленном окружении.
> Есть бранч, где был сделан бутстрап. Есть бранч, где старая версия.
> Как Вы получите в старом бранче уже отбустрапленное окружение, если
> нет возможности скопировать бинарные пакеты? Только повторение
> бутстрапа. На Эльбрусовой сборочнице именно так весь тулчейн
> и переносится. Благо, там есть бинарное копирование.
>
>> Может прийтись заново сделать бутстрап, если, например, в
>> целевом бранче версия libstdc++ ниже, чем та, с которой были
>> собраны копируемые бинарные пакеты, но речь идет про момент
>> бранчевание - первой сборки бранча, когда версии всех пакетов
>> одинаковые.
> Бранчевание — не одномоментный процесс. До заморозки много воды
> утечёт, да и после CVE никто не отменял.
>
В любом же случае стоит пересобрать скопированные пакеты, disttag станет включать в себя бранч. Вы их не пересобираете после такого копирования на Эльбрусовой сборочнице? Если пересобираете, то в чем проблема, не совсем понимаю.

Re: [devel] [JT] про команду, %ubt, -xalt и прочее разное

[Andrey Savchenko]

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

On Thu, 19 Nov 2020 19:15:07 +0300 Mikhail Novosyolov wrote:
> 19.11.2020 13:40, Andrey Savchenko пишет:
> > On Thu, 19 Nov 2020 10:08:42 +0300 Mikhail Novosyolov wrote:
[...]
> >> Можете привести примеры, где требуется повторить bootstrap?
> >>
> >> Обычно  достаточно просто пересобрать пакеты в уже отбутстрапленном окружении.
> > Есть бранч, где был сделан бутстрап. Есть бранч, где старая версия.
> > Как Вы получите в старом бранче уже отбустрапленное окружение, если
> > нет возможности скопировать бинарные пакеты? Только повторение
> > бутстрапа. На Эльбрусовой сборочнице именно так весь тулчейн
> > и переносится. Благо, там есть бинарное копирование.
> >
> >> Может прийтись заново сделать бутстрап, если, например, в
> >> целевом бранче версия libstdc++ ниже, чем та, с которой были
> >> собраны копируемые бинарные пакеты, но речь идет про момент
> >> бранчевание - первой сборки бранча, когда версии всех пакетов
> >> одинаковые.
> > Бранчевание — не одномоментный процесс. До заморозки много воды
> > утечёт, да и после CVE никто не отменял.
> >
> В любом же случае стоит пересобрать скопированные пакеты, disttag станет включать в себя бранч. Вы их не пересобираете после такого копирования на Эльбрусовой сборочнице? Если пересобираете, то в чем проблема, не совсем понимаю.

Разумеется, мы сперва копируем бинарные пакеты, затем их все
пересобираем.

В чём проблема? Вы понимаете, что такое бутстрап? Это проблема
курицы и яйца, например, когда для сборки нового тулчейна нужен
новый тулчейн.

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

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] [JT] про команду, %ubt, -xalt и прочее разное

[Mikhail Novosyolov]

19.11.2020 21:06, Andrey Savchenko пишет:
> On Thu, 19 Nov 2020 19:15:07 +0300 Mikhail Novosyolov wrote:
>> 19.11.2020 13:40, Andrey Savchenko пишет:
>>> On Thu, 19 Nov 2020 10:08:42 +0300 Mikhail Novosyolov wrote:
> [...]
>>>> Можете привести примеры, где требуется повторить bootstrap?
>>>>
>>>> Обычно  достаточно просто пересобрать пакеты в уже отбутстрапленном окружении.
>>> Есть бранч, где был сделан бутстрап. Есть бранч, где старая версия.
>>> Как Вы получите в старом бранче уже отбустрапленное окружение, если
>>> нет возможности скопировать бинарные пакеты? Только повторение
>>> бутстрапа. На Эльбрусовой сборочнице именно так весь тулчейн
>>> и переносится. Благо, там есть бинарное копирование.
>>>
>>>> Может прийтись заново сделать бутстрап, если, например, в
>>>> целевом бранче версия libstdc++ ниже, чем та, с которой были
>>>> собраны копируемые бинарные пакеты, но речь идет про момент
>>>> бранчевание - первой сборки бранча, когда версии всех пакетов
>>>> одинаковые.
>>> Бранчевание — не одномоментный процесс. До заморозки много воды
>>> утечёт, да и после CVE никто не отменял.
>>>
>> В любом же случае стоит пересобрать скопированные пакеты, disttag станет включать в себя бранч. Вы их не пересобираете после такого копирования на Эльбрусовой сборочнице? Если пересобираете, то в чем проблема, не совсем понимаю.
> Разумеется, мы сперва копируем бинарные пакеты, затем их все
> пересобираем.
>
> В чём проблема? Вы понимаете, что такое бутстрап? Это проблема
> курицы и яйца, например, когда для сборки нового тулчейна нужен
> новый тулчейн.
>
> Мы можем пересобрать пакеты только потому, что они до этого уже
> были скопированы бинарно и нам есть чем их пересобирать.
> В противном случае придётся повторять большое количество сложных
> промежуточных шагов, что займёт много как человеческого, так
> и машинного времени.

Конечно, понимаю. И понимаю, почему бутстрап - проблема при отсутствии возможности скопировать бинарные пакеты при бекпортировании в бранч.

Изначально вопрос был: почему вместо изобретения странных макросов нельзя смотреть на начало %disstag какого-либо пакета для определения целевого бранча? Например, rpm -q --qf '%{disttag}' glibc. Мне кажется, что так ненадежно делать только если не гарантируется, что лежащий в, допустим, p9 пакет не будет иметь disttag, начинающийся с sisyphus. Насколько понимаю и видел, сейчас такое часто встречается.

Если достигнуто состояние, когда пакеты можно пересобрать без бутстрапа, при этом не важно, достигнуто оно копированием бинарных пакетов или изнурительной ручной работой, у пакетов disttag окажется правилньым, если их просто пересобрать.

Re: [devel] [JT] про команду, %ubt, -xalt и прочее разное

[Anton V. Boyarshinov]

В Thu, 19 Nov 2020 19:10:10 +0300
Mikhail Novosyolov <mikhailnov@altlinux.org> пишет:

> 19.11.2020 11:33, Anton V. Boyarshinov пишет:
> > В Wed, 18 Nov 2020 23:19:51 +0300
> > Mikhail Novosyolov <mikhailnov@altlinux.org> пишет:
> >  
> >> А нельзя просто гарантированно пересобирать пакеты при копировании из сизифа в бранч, чтобы в %disstag появлялось p9, а потом на него смотреть?  
> > Вообще говоря, мы пытаемся решить скорее обратную задачу -- чтоб если
> > пакет из Сизифа при сборке в бранч существенно не изменился, то чтоб в
> > бранч попадал именно пакет из Сизифа, а не пересобранный.  
> А зачем? 
Что бы не плодить во множестве избыточные гигабайты. Для часто
собираемых больших пакетов типа ядра разница набегает немаленькая.

> И вы уверены, что set-versions настолько крут, что для гарантирования
целостности ABI не стоит пересобирать пакет?

Вот это и вкладывается в "существенно не изменился". Насколько я знаю,
проверяются  не только set-versions.

Re: [devel] [JT] про команду, %ubt, -xalt и прочее разное

[Mikhail Novosyolov]

20.11.2020 13:12, Anton V. Boyarshinov пишет:
> В Thu, 19 Nov 2020 19:10:10 +0300
> Mikhail Novosyolov <mikhailnov@altlinux.org> пишет:
>
>> 19.11.2020 11:33, Anton V. Boyarshinov пишет:
>>> В Wed, 18 Nov 2020 23:19:51 +0300
>>> Mikhail Novosyolov <mikhailnov@altlinux.org> пишет:
>>>  
>>>> А нельзя просто гарантированно пересобирать пакеты при копировании из сизифа в бранч, чтобы в %disstag появлялось p9, а потом на него смотреть?  
>>> Вообще говоря, мы пытаемся решить скорее обратную задачу -- чтоб если
>>> пакет из Сизифа при сборке в бранч существенно не изменился, то чтоб в
>>> бранч попадал именно пакет из Сизифа, а не пересобранный.  
>> А зачем? 
> Что бы не плодить во множестве избыточные гигабайты. Для часто
> собираемых больших пакетов типа ядра разница набегает немаленькая.
>
>> И вы уверены, что set-versions настолько крут, что для гарантирования
> целостности ABI не стоит пересобирать пакет?
>
> Вот это и вкладывается в "существенно не изменился". Насколько я знаю,
> проверяются  не только set-versions.

Выглядит сомнительно, т.к. риск поломать ABI и еще что-нибудь остается, как бы их ни проверяли. Но к ядру это не относится, копировать именно ядра, при условии, что в них не собираются perf и пр. утилиты, а скриптлеты точно подойдут для целевого бранча, не вижу принципиальных проблем.

Если остро стоит вопрос экономии места на дисках, то можно попробовать дедупликацию на уровне блоков в BTRFS [1, 2].  Насколько стабильно и надежно это работает, сказать не берусь, мне кажется, что не очень.


[1] https://github.com/Zygo/bees

[2] https://github.com/Zygo/bees/issues/116

Re: [devel] [JT] про команду, %ubt, -xalt и прочее разное

[Anton Farygin]

On 20.11.2020 15:03, Mikhail Novosyolov wrote:
> Если остро стоит вопрос экономии места на дисках, то можно попробовать дедупликацию на уровне блоков в BTRFS [1, 2].  Насколько стабильно и надежно это работает, сказать не берусь, мне кажется, что не очень.
>
>
> [1]https://github.com/Zygo/bees
>
> [2]https://github.com/Zygo/bees/issues/116

Дедупликация на уровне блоков не будет работать в случае с 
пересобранными и пережатыми RPM пакетами.

Ну и в btrfs оно так себе работает, мне не понравилось.

[devel] [JT] про btrfs

[Michael Shigorin]

On Fri, Nov 20, 2020 at 03:03:07PM +0300, Mikhail Novosyolov wrote:
> Если остро стоит вопрос экономии места на дисках, то можно
> попробовать дедупликацию на уровне блоков в BTRFS [1, 2]. 

Речь про этот btrfs?

http://lore.kernel.org/linux-btrfs/20200520013255.GD10769@hungrycats.org

(можно сразу с "A quick map of btrfs raid5/6 kernel bugs")

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] [JT] про btrfs

[Mikhail Novosyolov]

20.11.2020 15:13, Michael Shigorin пишет:
> On Fri, Nov 20, 2020 at 03:03:07PM +0300, Mikhail Novosyolov wrote:
>> Если остро стоит вопрос экономии места на дисках, то можно
>> попробовать дедупликацию на уровне блоков в BTRFS [1, 2]. 
> Речь про этот btrfs?
>
> http://lore.kernel.org/linux-btrfs/20200520013255.GD10769@hungrycats.org
>
> (можно сразу с "A quick map of btrfs raid5/6 kernel bugs")
>
Хорошая ссылка.

Резервные копии в других местах всегда должны быть. А перед тем, как на тыкаться на баги RAID5/6, можно посмотреть https://btrfs.wiki.kernel.org/index.php/Status и увидеть там особую пометку для RAID56.

Тот же автор документирует различные особенности здесь: https://github.com/Zygo/bees/tree/master/docs

Также стоит учитывать, что когда файловая система не контролирует целостность файлов проверкой их хешей, многие проблемы останутся просто незамеченными, жалоб от людей и попыток заставить файловую систему примонтироваться в rw будет больше.

Re: [devel] распознавание бранча

[Dmitry V. Levin]

On Fri, Nov 20, 2020 at 01:12:09PM +0300, Anton V. Boyarshinov wrote:
> В Thu, 19 Nov 2020 19:10:10 +0300, Mikhail Novosyolov пишет:
> > 19.11.2020 11:33, Anton V. Boyarshinov пишет:
> > > В Wed, 18 Nov 2020 23:19:51 +0300, Mikhail Novosyolov пишет:
> > >  
> > >> А нельзя просто гарантированно пересобирать пакеты при копировании из сизифа в бранч, чтобы в %disstag появлялось p9, а потом на него смотреть?  
> > > Вообще говоря, мы пытаемся решить скорее обратную задачу -- чтоб если
> > > пакет из Сизифа при сборке в бранч существенно не изменился, то чтоб в
> > > бранч попадал именно пакет из Сизифа, а не пересобранный.  
> > А зачем? 
> Что бы не плодить во множестве избыточные гигабайты. Для часто
> собираемых больших пакетов типа ядра разница набегает немаленькая.
> 
> > И вы уверены, что set-versions настолько крут, что для гарантирования
> целостности ABI не стоит пересобирать пакет?
> 
> Вот это и вкладывается в "существенно не изменился". Насколько я знаю,
> проверяются  не только set-versions.

Сейчас нет никакого копирования, операция copy - это всего лишь упрощенный
интерфейс операции сборки, когда нужная редакция исходников определяется
на стороне сервера.

Единственный случай, когда не происходит сборки - это в момент создания
бранча.  И это, на самом деле, большая проблема для всех подходов к
заглядыванию в %disttag/%ubt/whatever каких-либо пакетов, потому что
в этот момент там записана информация об исходном бранче.


-- 
ldv

Re: [devel] распознавание бранча -> %_priority_distbranch

[Anton Farygin]

On 20.11.2020 16:28, Dmitry V. Levin wrote:
> On Fri, Nov 20, 2020 at 01:12:09PM +0300, Anton V. Boyarshinov wrote:
>> В Thu, 19 Nov 2020 19:10:10 +0300, Mikhail Novosyolov пишет:
>>> 19.11.2020 11:33, Anton V. Boyarshinov пишет:
>>>> В Wed, 18 Nov 2020 23:19:51 +0300, Mikhail Novosyolov пишет:
>>>>> А нельзя просто гарантированно пересобирать пакеты при копировании 
>>>>> из сизифа в бранч, чтобы в %disstag появлялось p9, а потом на него 
>>>>> смотреть?
>>>> Вообще говоря, мы пытаемся решить скорее обратную задачу -- чтоб если
>>>> пакет из Сизифа при сборке в бранч существенно не изменился, то чтоб в
>>>> бранч попадал именно пакет из Сизифа, а не пересобранный.
>>> А зачем?
>> Что бы не плодить во множестве избыточные гигабайты. Для часто
>> собираемых больших пакетов типа ядра разница набегает немаленькая.
>>
>>> И вы уверены, что set-versions настолько крут, что для гарантирования
>> целостности ABI не стоит пересобирать пакет?
>>
>> Вот это и вкладывается в "существенно не изменился". Насколько я знаю,
>> проверяются не только set-versions.
> Сейчас нет никакого копирования, операция copy - это всего лишь упрощенный
> интерфейс операции сборки, когда нужная редакция исходников определяется
> на стороне сервера.
>
> Единственный случай, когда не происходит сборки - это в момент создания
> бранча. И это, на самом деле, большая проблема для всех подходов к
> заглядыванию в %disttag/%ubt/whatever каких-либо пакетов, потому что
> в этот момент там записана информация об исходном бранче.

Кстати, не знаю спрашивал я или нет, но мне просто интересно - как во 
времена p10 будет происходить апдейт с p9 до p10, если в бранче p10 
будет намешано пакетов и из sisyphus (таких же как в p9) и из p10, 
соответсвенно %_priority_distbranch в p10 уже не сработает.

Ну и в продолжение темы - может быть сделать общесистемный конфиг в 
отдельном пакете, в котором будет собственно этот самый branch в том или 
ином виде, таким образом, что бы его можно было распознавать и 
использовать в спеках.

Re: [devel] распознавание бранча -> %_priority_distbranch

[Dmitry V. Levin]

On Fri, Nov 20, 2020 at 06:12:02PM +0300, Anton Farygin wrote:
> On 20.11.2020 16:28, Dmitry V. Levin wrote:
> > On Fri, Nov 20, 2020 at 01:12:09PM +0300, Anton V. Boyarshinov wrote:
> >> В Thu, 19 Nov 2020 19:10:10 +0300, Mikhail Novosyolov пишет:
> >>> 19.11.2020 11:33, Anton V. Boyarshinov пишет:
> >>>> В Wed, 18 Nov 2020 23:19:51 +0300, Mikhail Novosyolov пишет:
> >>>>> А нельзя просто гарантированно пересобирать пакеты при копировании 
> >>>>> из сизифа в бранч, чтобы в %disstag появлялось p9, а потом на него 
> >>>>> смотреть?
> >>>> Вообще говоря, мы пытаемся решить скорее обратную задачу -- чтоб если
> >>>> пакет из Сизифа при сборке в бранч существенно не изменился, то чтоб в
> >>>> бранч попадал именно пакет из Сизифа, а не пересобранный.
> >>> А зачем?
> >> Что бы не плодить во множестве избыточные гигабайты. Для часто
> >> собираемых больших пакетов типа ядра разница набегает немаленькая.
> >>
> >>> И вы уверены, что set-versions настолько крут, что для гарантирования
> >> целостности ABI не стоит пересобирать пакет?
> >>
> >> Вот это и вкладывается в "существенно не изменился". Насколько я знаю,
> >> проверяются не только set-versions.
> > Сейчас нет никакого копирования, операция copy - это всего лишь упрощенный
> > интерфейс операции сборки, когда нужная редакция исходников определяется
> > на стороне сервера.
> >
> > Единственный случай, когда не происходит сборки - это в момент создания
> > бранча. И это, на самом деле, большая проблема для всех подходов к
> > заглядыванию в %disttag/%ubt/whatever каких-либо пакетов, потому что
> > в этот момент там записана информация об исходном бранче.
> 
> Кстати, не знаю спрашивал я или нет, но мне просто интересно - как во 
> времена p10 будет происходить апдейт с p9 до p10, если в бранче p10 
> будет намешано пакетов и из sisyphus (таких же как в p9) и из p10, 
> соответсвенно %_priority_distbranch в p10 уже не сработает.

По идее, если определить %_priority_distbranch в p10, то приоритет
получится следующий: p10 > sisyphus > p9.

> Ну и в продолжение темы - может быть сделать общесистемный конфиг в 
> отдельном пакете, в котором будет собственно этот самый branch в том или 
> ином виде, таким образом, что бы его можно было распознавать и 
> использовать в спеках.

Тогда этот пакет должен быть первым, который собирается в новый бранч.
Сейчас таким пакетом является altlinux-release-$branch.


-- 
ldv

Re: [devel] [JT] про команду, %ubt, -xalt и прочее разное

[Vitaly Lipatov]

Sergey V Turchin писал 19.11.20 10:51:
...
> Ну, вот, мой без костыля теперь не получается использовать, т.к. 
> сборочница
> предательски и абсолютно незаслуженно убивает значение макроса %ubt_id.
Ах вот что... :(

> Если ты у себя сделаешь значения _distro_version пригодные для 
> сравнения, то
> сможешь пользоваться макросами сравнения версий 
> http://bugs.altlinux.org/6010
Спасибо за напоминание!
У меня возникло большое подозрение в монотонности роста названия бранча, 
особенно после того, как назвали сертифицированный бранч p9.

-- 
С уважением,
Виталий Липатов,
ALT Linux Team

Re: [devel] распознавание бранча

[Mikhail Novosyolov]

20.11.2020 16:28, Dmitry V. Levin пишет:
> On Fri, Nov 20, 2020 at 01:12:09PM +0300, Anton V. Boyarshinov wrote:
>> В Thu, 19 Nov 2020 19:10:10 +0300, Mikhail Novosyolov пишет:
>>> 19.11.2020 11:33, Anton V. Boyarshinov пишет:
>>>> В Wed, 18 Nov 2020 23:19:51 +0300, Mikhail Novosyolov пишет:
>>>>  
>>>>> А нельзя просто гарантированно пересобирать пакеты при копировании из сизифа в бранч, чтобы в %disstag появлялось p9, а потом на него смотреть?  
>>>> Вообще говоря, мы пытаемся решить скорее обратную задачу -- чтоб если
>>>> пакет из Сизифа при сборке в бранч существенно не изменился, то чтоб в
>>>> бранч попадал именно пакет из Сизифа, а не пересобранный.  
>>> А зачем? 
>> Что бы не плодить во множестве избыточные гигабайты. Для часто
>> собираемых больших пакетов типа ядра разница набегает немаленькая.
>>
>>> И вы уверены, что set-versions настолько крут, что для гарантирования
>> целостности ABI не стоит пересобирать пакет?
>>
>> Вот это и вкладывается в "существенно не изменился". Насколько я знаю,
>> проверяются  не только set-versions.
> Сейчас нет никакого копирования, операция copy - это всего лишь упрощенный
> интерфейс операции сборки, когда нужная редакция исходников определяется
> на стороне сервера.
>
> Единственный случай, когда не происходит сборки - это в момент создания
> бранча.  И это, на самом деле, большая проблема для всех подходов к
> заглядыванию в %disttag/%ubt/whatever каких-либо пакетов, потому что
> в этот момент там записана информация об исходном бранче.
Отсутствие полной пересборки после бранчевания - это просто экономия времени и машинных ресурсов (вряд ли), или чем-то еще обусловлено?

Re: [devel] распознавание бранча -> %_priority_distbranch

[Vitaly Lipatov]

Dmitry V. Levin писал 20.11.20 18:20:
...
>> Ну и в продолжение темы - может быть сделать общесистемный конфиг в
>> отдельном пакете, в котором будет собственно этот самый branch в том 
>> или
>> ином виде, таким образом, что бы его можно было распознавать и
>> использовать в спеках.
> 
> Тогда этот пакет должен быть первым, который собирается в новый бранч.
> Сейчас таким пакетом является altlinux-release-$branch.
И %_distro_version, от которого обсуждение пошло в эту сторону, 
предоставляется rpm-build-intro и заполняется по информации от 
distro_info, получаемой из /etc/altlinux-release, находящегося в 
altlinux-release-$branch.

Но тогда уж надо обсуждать, почему rpm-build не может нам гарантировать 
присутствие пригодной для сравнения информации о бранче.

Конечно, конструкции вида
%if 0%{?fedora} && 0%{?fedora} < 19
  --vendor="fedora"    \
%endif

выглядят развесисто. Но у них есть простой макрос fedora с версией.

И на самом деле важна не версия. А важна определённая фича, которая есть 
в бранче или нет.
Например, вместо
%if %_vendor == "alt" && (%_distro_version == "p9" || %_distro_version 
== "Sisyphus")
BuildRequires: libvulkan-devel
%endif

Я бы хотел писать
%if_have vulkan
BuildRequires: libvulkan-devel
%endif

а не гадать, в каком же бранче есть vulkan, а в каком ещё нет.

-- 
С уважением,
Виталий Липатов,
ALT Linux Team

Re: [devel] распознавание бранча -> %_priority_distbranch

[Mikhail Novosyolov]

20.11.2020 19:26, Vitaly Lipatov пишет:
> Dmitry V. Levin писал 20.11.20 18:20:
> ...
>>> Ну и в продолжение темы - может быть сделать общесистемный конфиг в
>>> отдельном пакете, в котором будет собственно этот самый branch в том или
>>> ином виде, таким образом, что бы его можно было распознавать и
>>> использовать в спеках.
>>
>> Тогда этот пакет должен быть первым, который собирается в новый бранч.
>> Сейчас таким пакетом является altlinux-release-$branch.
> И %_distro_version, от которого обсуждение пошло в эту сторону, предоставляется rpm-build-intro и заполняется по информации от distro_info, получаемой из /etc/altlinux-release, находящегося в altlinux-release-$branch.
>
> Но тогда уж надо обсуждать, почему rpm-build не может нам гарантировать присутствие пригодной для сравнения информации о бранче.
>
> Конечно, конструкции вида
> %if 0%{?fedora} && 0%{?fedora} < 19
>  --vendor="fedora"    \
> %endif
>
> выглядят развесисто. Но у них есть простой макрос fedora с версией.
>
> И на самом деле важна не версия. А важна определённая фича, которая есть в бранче или нет.
> Например, вместо
> %if %_vendor == "alt" && (%_distro_version == "p9" || %_distro_version == "Sisyphus")
> BuildRequires: libvulkan-devel
> %endif
>
> Я бы хотел писать
> %if_have vulkan
> BuildRequires: libvulkan-devel
> %endif
>
> а не гадать, в каком же бранче есть vulkan, а в каком ещё нет.

Опыт другого дистрибутива показывает, что про эти фичи - переключалки типа %bcond_with vulkan на весь репозиторий - никто не помнит и не использует.

vulkan теперь будет везде, точно ли есть смысл рождать переключалку ради рудимента - отсутствия vulkan в древних бранчах?

Re: [devel] сборка пакета, опирающаяся на свойства бранча

[Vitaly Lipatov]

Mikhail Novosyolov писал 20.11.20 19:47:
...
>> И на самом деле важна не версия. А важна определённая фича, которая 
>> есть в бранче или нет.
>> Например, вместо
>> %if %_vendor == "alt" && (%_distro_version == "p9" || %_distro_version 
>> == "Sisyphus")
>> BuildRequires: libvulkan-devel
>> %endif
>> 
>> Я бы хотел писать
>> %if_have vulkan
>> BuildRequires: libvulkan-devel
>> %endif
>> 
>> а не гадать, в каком же бранче есть vulkan, а в каком ещё нет.
> 
> Опыт другого дистрибутива показывает, что про эти фичи - переключалки
> типа %bcond_with vulkan на весь репозиторий - никто не помнит и не
> использует.
Важная мысль. Но, как я понимаю. конкретно bcond_with это аналог наших 
def_with и предназначены для другого:
https://github.com/redhat-developer/rpm-packaging-guide/issues/23

Моё предложение — задавать некоторые такие условия глобально для бранча. 
Есть ли у кого-нибудь информация о существующих аналогиях или 
противопоказаниях?

> vulkan теперь будет везде, точно ли есть смысл рождать переключалку
> ради рудимента - отсутствия vulkan в древних бранчах?
К сожалению, всегда будет такой бранч, в котором что-то отсутствует, но 
туда нужно собрать пакет. Это я говорю как собиравший в p8 пакеты с 
ffmpeg, которого там не было.

-- 
С уважением,
Виталий Липатов,
ALT Linux Team

Re: [devel] распознавание бранча

[Dmitry V. Levin]

On Fri, Nov 20, 2020 at 07:24:59PM +0300, Mikhail Novosyolov wrote:
> 
> 20.11.2020 16:28, Dmitry V. Levin пишет:
> > On Fri, Nov 20, 2020 at 01:12:09PM +0300, Anton V. Boyarshinov wrote:
> >> В Thu, 19 Nov 2020 19:10:10 +0300, Mikhail Novosyolov пишет:
> >>> 19.11.2020 11:33, Anton V. Boyarshinov пишет:
> >>>> В Wed, 18 Nov 2020 23:19:51 +0300, Mikhail Novosyolov пишет:
> >>>>  
> >>>>> А нельзя просто гарантированно пересобирать пакеты при копировании из сизифа в бранч, чтобы в %disstag появлялось p9, а потом на него смотреть?  
> >>>> Вообще говоря, мы пытаемся решить скорее обратную задачу -- чтоб если
> >>>> пакет из Сизифа при сборке в бранч существенно не изменился, то чтоб в
> >>>> бранч попадал именно пакет из Сизифа, а не пересобранный.  
> >>> А зачем? 
> >> Что бы не плодить во множестве избыточные гигабайты. Для часто
> >> собираемых больших пакетов типа ядра разница набегает немаленькая.
> >>
> >>> И вы уверены, что set-versions настолько крут, что для гарантирования
> >> целостности ABI не стоит пересобирать пакет?
> >>
> >> Вот это и вкладывается в "существенно не изменился". Насколько я знаю,
> >> проверяются  не только set-versions.
> > Сейчас нет никакого копирования, операция copy - это всего лишь упрощенный
> > интерфейс операции сборки, когда нужная редакция исходников определяется
> > на стороне сервера.
> >
> > Единственный случай, когда не происходит сборки - это в момент создания
> > бранча.  И это, на самом деле, большая проблема для всех подходов к
> > заглядыванию в %disttag/%ubt/whatever каких-либо пакетов, потому что
> > в этот момент там записана информация об исходном бранче.
> Отсутствие полной пересборки после бранчевания - это просто экономия времени и машинных ресурсов (вряд ли), или чем-то еще обусловлено?

Полная пересборка после бранчевания - это концептуально неправильно,
по-хорошему, пересобирать нужно всегда, когда результат пересборки
меняется, не дожидаясь бранчевания.


-- 
ldv

Re: [devel] распознавание бранча

[Anton Farygin]

On 20.11.2020 20:47, Dmitry V. Levin wrote:
> On Fri, Nov 20, 2020 at 07:24:59PM +0300, Mikhail Novosyolov wrote:
>> 20.11.2020 16:28, Dmitry V. Levin пишет:
>>> On Fri, Nov 20, 2020 at 01:12:09PM +0300, Anton V. Boyarshinov wrote:
>>>> В Thu, 19 Nov 2020 19:10:10 +0300, Mikhail Novosyolov пишет:
>>>>> 19.11.2020 11:33, Anton V. Boyarshinov пишет:
>>>>>> В Wed, 18 Nov 2020 23:19:51 +0300, Mikhail Novosyolov пишет:
>>>>>>   
>>>>>>> А нельзя просто гарантированно пересобирать пакеты при копировании из сизифа в бранч, чтобы в %disstag появлялось p9, а потом на него смотреть?
>>>>>> Вообще говоря, мы пытаемся решить скорее обратную задачу -- чтоб если
>>>>>> пакет из Сизифа при сборке в бранч существенно не изменился, то чтоб в
>>>>>> бранч попадал именно пакет из Сизифа, а не пересобранный.
>>>>> А зачем?
>>>> Что бы не плодить во множестве избыточные гигабайты. Для часто
>>>> собираемых больших пакетов типа ядра разница набегает немаленькая.
>>>>
>>>>> И вы уверены, что set-versions настолько крут, что для гарантирования
>>>> целостности ABI не стоит пересобирать пакет?
>>>>
>>>> Вот это и вкладывается в "существенно не изменился". Насколько я знаю,
>>>> проверяются  не только set-versions.
>>> Сейчас нет никакого копирования, операция copy - это всего лишь упрощенный
>>> интерфейс операции сборки, когда нужная редакция исходников определяется
>>> на стороне сервера.
>>>
>>> Единственный случай, когда не происходит сборки - это в момент создания
>>> бранча.  И это, на самом деле, большая проблема для всех подходов к
>>> заглядыванию в %disttag/%ubt/whatever каких-либо пакетов, потому что
>>> в этот момент там записана информация об исходном бранче.
>> Отсутствие полной пересборки после бранчевания - это просто экономия времени и машинных ресурсов (вряд ли), или чем-то еще обусловлено?
> Полная пересборка после бранчевания - это концептуально неправильно,
> по-хорошему, пересобирать нужно всегда, когда результат пересборки
> меняется, не дожидаясь бранчевания.
>
>
согласен.  не очень сложно выяснить, нужно ли пересобирать пакет.

а ещё если это делать в процессе бранчевания - то у пакетов вырастет 
buildtime и они из старых станут новыми (соответственно обновятся).

Re: [devel] сборка пакета, опирающаяся на свойства бранча

[Mikhail Novosyolov]

20.11.2020 20:39, Vitaly Lipatov пишет:
> Mikhail Novosyolov писал 20.11.20 19:47:
> ...
>>> И на самом деле важна не версия. А важна определённая фича, которая есть в бранче или нет.
>>> Например, вместо
>>> %if %_vendor == "alt" && (%_distro_version == "p9" || %_distro_version == "Sisyphus")
>>> BuildRequires: libvulkan-devel
>>> %endif
>>>
>>> Я бы хотел писать
>>> %if_have vulkan
>>> BuildRequires: libvulkan-devel
>>> %endif
>>>
>>> а не гадать, в каком же бранче есть vulkan, а в каком ещё нет.
>>
>> Опыт другого дистрибутива показывает, что про эти фичи - переключалки
>> типа %bcond_with vulkan на весь репозиторий - никто не помнит и не
>> использует.
> Важная мысль. Но, как я понимаю. конкретно bcond_with это аналог наших def_with и предназначены для другого:
> https://github.com/redhat-developer/rpm-packaging-guide/issues/23

Да это то же самое

%bcond_without foo

%if %{with foo}
<...>
%endif

Такая конструкция эквивалентна rpmbuild --with=foo (with и without реверсированы в %bcond_with(out)), можно при этом сделать rpmbuild --without=foo для отключения foo.

В пакете branding-configs / distro-release задается глобальный для "бранча" список переключалок:
%bcond_without selinux
%bcond_with foo
и т.д.
Далее в спеках можно подтягивать эти глобальные значения.

Как я понимаю, это именно то, что Вы описали для vulkan. Приведет к тому, что лет через 5 будет огромный список таких глобальных переключалок, подавляющее большинство которых не нужно будет для актуальных бранчей, но они будут тянуться годами, на весь репозиторий будет полтора пакета, их использующих, в большинстве из которых они будут и не нужны к тому времени. А еще будет сложный процесс согласования добавления переключалок, скорее всего.

>
> Моё предложение — задавать некоторые такие условия глобально для бранча. Есть ли у кого-нибудь информация о существующих аналогиях или противопоказаниях?
>
>> vulkan теперь будет везде, точно ли есть смысл рождать переключалку
>> ради рудимента - отсутствия vulkan в древних бранчах?
> К сожалению, всегда будет такой бранч, в котором что-то отсутствует, но туда нужно собрать пакет. Это я говорю как собиравший в p8 пакеты с ffmpeg, которого там не было.

Re: [devel] распознавание бранча

[Mikhail Novosyolov]

20.11.2020 20:52, Anton Farygin пишет:
> On 20.11.2020 20:47, Dmitry V. Levin wrote:
>> On Fri, Nov 20, 2020 at 07:24:59PM +0300, Mikhail Novosyolov wrote:
>>> 20.11.2020 16:28, Dmitry V. Levin пишет:
>>>> On Fri, Nov 20, 2020 at 01:12:09PM +0300, Anton V. Boyarshinov wrote:
>>>>> В Thu, 19 Nov 2020 19:10:10 +0300, Mikhail Novosyolov пишет:
>>>>>> 19.11.2020 11:33, Anton V. Boyarshinov пишет:
>>>>>>> В Wed, 18 Nov 2020 23:19:51 +0300, Mikhail Novosyolov пишет:
>>>>>>>  
>>>>>>>> А нельзя просто гарантированно пересобирать пакеты при копировании из сизифа в бранч, чтобы в %disstag появлялось p9, а потом на него смотреть?
>>>>>>> Вообще говоря, мы пытаемся решить скорее обратную задачу -- чтоб если
>>>>>>> пакет из Сизифа при сборке в бранч существенно не изменился, то чтоб в
>>>>>>> бранч попадал именно пакет из Сизифа, а не пересобранный.
>>>>>> А зачем?
>>>>> Что бы не плодить во множестве избыточные гигабайты. Для часто
>>>>> собираемых больших пакетов типа ядра разница набегает немаленькая.
>>>>>
>>>>>> И вы уверены, что set-versions настолько крут, что для гарантирования
>>>>> целостности ABI не стоит пересобирать пакет?
>>>>>
>>>>> Вот это и вкладывается в "существенно не изменился". Насколько я знаю,
>>>>> проверяются  не только set-versions.
>>>> Сейчас нет никакого копирования, операция copy - это всего лишь упрощенный
>>>> интерфейс операции сборки, когда нужная редакция исходников определяется
>>>> на стороне сервера.
>>>>
>>>> Единственный случай, когда не происходит сборки - это в момент создания
>>>> бранча.  И это, на самом деле, большая проблема для всех подходов к
>>>> заглядыванию в %disttag/%ubt/whatever каких-либо пакетов, потому что
>>>> в этот момент там записана информация об исходном бранче.
>>> Отсутствие полной пересборки после бранчевания - это просто экономия времени и машинных ресурсов (вряд ли), или чем-то еще обусловлено?
>> Полная пересборка после бранчевания - это концептуально неправильно,
>> по-хорошему, пересобирать нужно всегда, когда результат пересборки
>> меняется, не дожидаясь бранчевания.
>>
>>
> согласен.  не очень сложно выяснить, нужно ли пересобирать пакет.
Недавно в devel@ обсуждался хороший пример, почему это не совсем так: многие пакеты используют лишь заголовки из boost, не линкуясь с ним, все методы определения необходимости пересборки покажут, что пересборка не нужна, но ведь она нужна для уверенности в поддержании пакета в пересобираемом состоянии как минимум. Также могут меняться структуры данных и пр., оставляя внешние символы теми же самыми, такое тоже не отловится существующим инструментарием, гораздо надежнее пересобрать.
>
> а ещё если это делать в процессе бранчевания - то у пакетов вырастет buildtime и они из старых станут новыми (соответственно обновятся).
>
А чем это помешает, особенно с учетом приоритета бранчей в apt? Обновятся-то в новорожденном бранче, которым еще никто не пользуется, а не в сизифе.

Re: [devel] распознавание бранча

[Mikhail Novosyolov]

20.11.2020 20:47, Dmitry V. Levin пишет:
>> Отсутствие полной пересборки после бранчевания - это просто экономия времени и машинных ресурсов (вряд ли), или чем-то еще обусловлено?
> Полная пересборка после бранчевания - это концептуально неправильно,
> по-хорошему, пересобирать нужно всегда, когда результат пересборки
> меняется, не дожидаясь бранчевания.
Получается, концепция - избегать лишних пересборок, чтобы, если пакеты одинаковые, по возможности они были, так сказать, совсем одинаковыми, чтобы избежать лишних непредвиденных изменений в работе?

Re: [devel] сборка пакета, опирающаяся на свойства бранча

[Vitaly Lipatov]

Mikhail Novosyolov писал 20.11.20 21:32:
...
> Да это то же самое
> 
> %bcond_without foo
> 
> %if %{with foo}
> <...>
> %endif
> 
> Такая конструкция эквивалентна rpmbuild --with=foo (with и without
> реверсированы в %bcond_with(out)), можно при этом сделать rpmbuild
> --without=foo для отключения foo.
> 
> В пакете branding-configs / distro-release задается глобальный для
> "бранча" список переключалок:
> %bcond_without selinux
> %bcond_with foo
> и т.д.
> Далее в спеках можно подтягивать эти глобальные значения.
Ага...

> Как я понимаю, это именно то, что Вы описали для vulkan. Приведет к
> тому, что лет через 5 будет огромный список таких глобальных
> переключалок, подавляющее большинство которых не нужно будет для
> актуальных бранчей, но они будут тянуться годами, на весь репозиторий
> будет полтора пакета, их использующих, в большинстве из которых они
> будут и не нужны к тому времени. А еще будет сложный процесс
> согласования добавления переключалок, скорее всего.
Спасибо за опыт. У меня тоже опыт поддержки таких штук.
Устраивать это надо иначе:
в условном rpm-macros-branch-config для _старых_ бранчей отключается то,
что там не поддерживается. Таким образом эти настройки потом умирают 
вместе с бранчем.
Да, будет требоваться обновлять в поддерживаемых бранчах этот пакет при 
появлении чего-то в Сизифе, что требует условной сборки.

Например, я бы хотел для p8/c8:
# отсутствие ffmpeg
%def_without ffmpeg
# отсутствие vulkan и использующих его библиотек
%def_without vulkan
# отсутствие faudio
%def_without faudio

То есть это не свойство бранча, а ретроспективный сожалеющий взгляд на 
то, чего там нет.


-- 
С уважением,
Виталий Липатов,
ALT Linux Team

Re: [devel] сборка пакета, опирающаяся на свойства бранча

[Антон Мидюков]

21.11.2020 02:20, Vitaly Lipatov пишет:
> Mikhail Novosyolov писал 20.11.20 21:32:
> ...
>> Да это то же самое
>>
>> %bcond_without foo
>>
>> %if %{with foo}
>> <...>
>> %endif
>>
>> Такая конструкция эквивалентна rpmbuild --with=foo (with и without
>> реверсированы в %bcond_with(out)), можно при этом сделать rpmbuild
>> --without=foo для отключения foo.
>>
>> В пакете branding-configs / distro-release задается глобальный для
>> "бранча" список переключалок:
>> %bcond_without selinux
>> %bcond_with foo
>> и т.д.
>> Далее в спеках можно подтягивать эти глобальные значения.
> Ага...
>
>> Как я понимаю, это именно то, что Вы описали для vulkan. Приведет к
>> тому, что лет через 5 будет огромный список таких глобальных
>> переключалок, подавляющее большинство которых не нужно будет для
>> актуальных бранчей, но они будут тянуться годами, на весь репозиторий
>> будет полтора пакета, их использующих, в большинстве из которых они
>> будут и не нужны к тому времени. А еще будет сложный процесс
>> согласования добавления переключалок, скорее всего.
> Спасибо за опыт. У меня тоже опыт поддержки таких штук.
> Устраивать это надо иначе:
> в условном rpm-macros-branch-config для _старых_ бранчей отключается то,
> что там не поддерживается. Таким образом эти настройки потом умирают 
> вместе с бранчем.
> Да, будет требоваться обновлять в поддерживаемых бранчах этот пакет 
> при появлении чего-то в Сизифе, что требует условной сборки.
>
> Например, я бы хотел для p8/c8:
> # отсутствие ffmpeg
> %def_without ffmpeg
> # отсутствие vulkan и использующих его библиотек
> %def_without vulkan
> # отсутствие faudio
> %def_without faudio
>
> То есть это не свойство бранча, а ретроспективный сожалеющий взгляд на 
> то, чего там нет.
>
А в чём проблема сейчас такой пакет сделать и собрать во все бранчи?

Кому надо, подключит в спеке

BuildRequires(pre): rpm-macros-branch-config

-- 
С уважением, Антон Мидюков <antohami@altlinux.org>

Re: [devel] сборка пакета, опирающаяся на свойства бранча

[Mikhail Novosyolov]

20.11.2020 22:20, Vitaly Lipatov пишет:
> Mikhail Novosyolov писал 20.11.20 21:32:
> ...
>> Да это то же самое
>>
>> %bcond_without foo
>>
>> %if %{with foo}
>> <...>
>> %endif
>>
>> Такая конструкция эквивалентна rpmbuild --with=foo (with и without
>> реверсированы в %bcond_with(out)), можно при этом сделать rpmbuild
>> --without=foo для отключения foo.
>>
>> В пакете branding-configs / distro-release задается глобальный для
>> "бранча" список переключалок:
>> %bcond_without selinux
>> %bcond_with foo
>> и т.д.
>> Далее в спеках можно подтягивать эти глобальные значения.
> Ага...
>
>> Как я понимаю, это именно то, что Вы описали для vulkan. Приведет к
>> тому, что лет через 5 будет огромный список таких глобальных
>> переключалок, подавляющее большинство которых не нужно будет для
>> актуальных бранчей, но они будут тянуться годами, на весь репозиторий
>> будет полтора пакета, их использующих, в большинстве из которых они
>> будут и не нужны к тому времени. А еще будет сложный процесс
>> согласования добавления переключалок, скорее всего.
> Спасибо за опыт. У меня тоже опыт поддержки таких штук.
> Устраивать это надо иначе:
> в условном rpm-macros-branch-config для _старых_ бранчей отключается то,
> что там не поддерживается. Таким образом эти настройки потом умирают вместе с бранчем.
> Да, будет требоваться обновлять в поддерживаемых бранчах этот пакет при появлении чего-то в Сизифе, что требует условной сборки.
>
> Например, я бы хотел для p8/c8:
> # отсутствие ffmpeg
> %def_without ffmpeg
> # отсутствие vulkan и использующих его библиотек
> %def_without vulkan
> # отсутствие faudio
> %def_without faudio
>
> То есть это не свойство бранча, а ретроспективный сожалеющий взгляд на то, чего там нет.

То есть при этом "%def_with vulkan" в условном rpm-macros-branch-config писать не придется? Тогда это выглядит лучше. Но желательно придумать механизм, чтобы в спеке для сизифа, в rpm-macros-branch-config которого вообще не будет ничего про ffmpeg, не пришлось писать далеко не всем понятные конструкции типа

%{?build_selinux}%{?!build_selinux:%bcond_with selinux}

Т.е., другими словами, rpm-build должен подгружать %def_without из файла макросов, а не только лишь из спека.

Re: [devel] комментарий про %bcond_without

[Dmitry V. Levin]

On Fri, Nov 20, 2020 at 09:32:51PM +0300, Mikhail Novosyolov wrote:
[...]
> Да это то же самое
> 
> %bcond_without foo

У них
%bcond_without foo
означает то же самое, что у нас
%def_with foo
т.е. по умолчанию with foo, если не сказано rpmbuild --without=foo.

Вдумайтесь ещё раз:
%bcond_without foo означает, что по умолчанию --with=foo.
Это гениально, я считаю.


-- 
ldv

Re: [devel] пересборка

[Dmitry V. Levin]

On Fri, Nov 20, 2020 at 09:40:58PM +0300, Mikhail Novosyolov wrote:
> 
> 20.11.2020 20:52, Anton Farygin пишет:
> > On 20.11.2020 20:47, Dmitry V. Levin wrote:
> >> On Fri, Nov 20, 2020 at 07:24:59PM +0300, Mikhail Novosyolov wrote:
[...]
> >>> Отсутствие полной пересборки после бранчевания - это просто экономия времени и машинных ресурсов (вряд ли), или чем-то еще обусловлено?
> >> Полная пересборка после бранчевания - это концептуально неправильно,
> >> по-хорошему, пересобирать нужно всегда, когда результат пересборки
> >> меняется, не дожидаясь бранчевания.
> >>
> > согласен.  не очень сложно выяснить, нужно ли пересобирать пакет.
> Недавно в devel@ обсуждался хороший пример, почему это не совсем так: многие пакеты используют лишь заголовки из boost, не линкуясь с ним, все методы определения необходимости пересборки покажут, что пересборка не нужна, но ведь она нужна для уверенности в поддержании пакета в пересобираемом состоянии как минимум. Также могут меняться структуры данных и пр., оставляя внешние символы теми же самыми, такое тоже не отловится существующим инструментарием, гораздо надежнее пересобрать.

Лучше всего, когда уверенность основывается на знании.

Если все методы определения необходимости пересборки покажут, что
пересборка не нужна, значит, либо методы неправильные, либо пересборка
действительно не нужна.

Например, если NT_GNU_BUILD_ID у файла после пересборки с другим boost
не поменялся, значит, его пересобирать не надо.

Грубо говоря, алгоритм может быть такой:
1. определяем все пакеты, у которых поменялась сборочная среда;
2. пересобираем все эти пакеты;
3. те из них, которые в результате пересборки поменялись, коммитим в репозиторий.


-- 
ldv

Re: [devel] [JT] про команду, %ubt, -xalt и прочее разное

[Vladimir D. Seleznev]

On Wed, Nov 18, 2020 at 10:41:50AM +0300, Sergey V Turchin wrote:
> On Tuesday, 17 November 2020 21:56:18 MSK Michael Shigorin wrote:
> > On Tue, Nov 17, 2020 at 04:29:58PM +0300, Sergey V Turchin wrote:
> > > Ещё подгадил админ сборочницы
> > 
> > Ну вообще-то сперва кое-кто единолично нагадил %ubt,
> Тут, понимаешь ли, лишь буквы похожие.
> Это совсем другая фича, которая не имеет ничего общего с тем, о чем ты и 
> используется мной до сих пор, т.к. аналог я 1-й раз вижу у Виталия, но у меня 
> покруче, т.к. позволяет не только ==, но и <, <, >= и т.д.

Как работают эти отношения для сравнения с другими бранчами (t*, c*, и
т.д.) и Сизифом? У нас же, вообще говоря, нет линейного порядка бранчей.

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] распознавание бранча

[Vladimir D. Seleznev]

On Fri, Nov 20, 2020 at 08:47:05PM +0300, Dmitry V. Levin wrote:
> On Fri, Nov 20, 2020 at 07:24:59PM +0300, Mikhail Novosyolov wrote:
> > 
> > 20.11.2020 16:28, Dmitry V. Levin пишет:
> > > On Fri, Nov 20, 2020 at 01:12:09PM +0300, Anton V. Boyarshinov wrote:
> > >> В Thu, 19 Nov 2020 19:10:10 +0300, Mikhail Novosyolov пишет:
> > >>> 19.11.2020 11:33, Anton V. Boyarshinov пишет:
> > >>>> В Wed, 18 Nov 2020 23:19:51 +0300, Mikhail Novosyolov пишет:
> > >>>>  
> > >>>>> А нельзя просто гарантированно пересобирать пакеты при копировании из сизифа в бранч, чтобы в %disstag появлялось p9, а потом на него смотреть?  
> > >>>> Вообще говоря, мы пытаемся решить скорее обратную задачу -- чтоб если
> > >>>> пакет из Сизифа при сборке в бранч существенно не изменился, то чтоб в
> > >>>> бранч попадал именно пакет из Сизифа, а не пересобранный.  
> > >>> А зачем? 
> > >> Что бы не плодить во множестве избыточные гигабайты. Для часто
> > >> собираемых больших пакетов типа ядра разница набегает немаленькая.
> > >>
> > >>> И вы уверены, что set-versions настолько крут, что для гарантирования
> > >> целостности ABI не стоит пересобирать пакет?
> > >>
> > >> Вот это и вкладывается в "существенно не изменился". Насколько я знаю,
> > >> проверяются  не только set-versions.
> > > Сейчас нет никакого копирования, операция copy - это всего лишь упрощенный
> > > интерфейс операции сборки, когда нужная редакция исходников определяется
> > > на стороне сервера.
> > >
> > > Единственный случай, когда не происходит сборки - это в момент создания
> > > бранча.  И это, на самом деле, большая проблема для всех подходов к
> > > заглядыванию в %disttag/%ubt/whatever каких-либо пакетов, потому что
> > > в этот момент там записана информация об исходном бранче.
> > Отсутствие полной пересборки после бранчевания - это просто экономия времени и машинных ресурсов (вряд ли), или чем-то еще обусловлено?
> 
> Полная пересборка после бранчевания - это концептуально неправильно,
> по-хорошему, пересобирать нужно всегда, когда результат пересборки
> меняется, не дожидаясь бранчевания.

А зачем? Просто пересобранный пакет может внезапно оказаться нерабочим,
а кто чинить будет?

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] пересборка

[Dmitry V. Levin]

On Sat, Nov 21, 2020 at 05:46:19AM +0300, Vladimir D. Seleznev wrote:
> On Fri, Nov 20, 2020 at 08:47:05PM +0300, Dmitry V. Levin wrote:
> > On Fri, Nov 20, 2020 at 07:24:59PM +0300, Mikhail Novosyolov wrote:
[...]
> > > Отсутствие полной пересборки после бранчевания - это просто экономия времени и машинных ресурсов (вряд ли), или чем-то еще обусловлено?
> > 
> > Полная пересборка после бранчевания - это концептуально неправильно,
> > по-хорошему, пересобирать нужно всегда, когда результат пересборки
> > меняется, не дожидаясь бранчевания.
> 
> А зачем? Просто пересобранный пакет может внезапно оказаться нерабочим,
> а кто чинить будет?

Чем раньше он окажется нерабочим, тем раньше об этом узнают те,
кто могут починить.  А вообще в нормальном пакете должны быть тесты.


-- 
ldv

Re: [devel] [JT] про команду, %ubt, -xalt и прочее разное

[Dmitry V. Levin]

On Sat, Nov 21, 2020 at 05:41:56AM +0300, Vladimir D. Seleznev wrote:
> On Wed, Nov 18, 2020 at 10:41:50AM +0300, Sergey V Turchin wrote:
> > On Tuesday, 17 November 2020 21:56:18 MSK Michael Shigorin wrote:
> > > On Tue, Nov 17, 2020 at 04:29:58PM +0300, Sergey V Turchin wrote:
> > > > Ещё подгадил админ сборочницы
> > > 
> > > Ну вообще-то сперва кое-кто единолично нагадил %ubt,
> > Тут, понимаешь ли, лишь буквы похожие.
> > Это совсем другая фича, которая не имеет ничего общего с тем, о чем ты и 
> > используется мной до сих пор, т.к. аналог я 1-й раз вижу у Виталия, но у меня 
> > покруче, т.к. позволяет не только ==, но и <, <, >= и т.д.
> 
> Как работают эти отношения для сравнения с другими бранчами (t*, c*, и
> т.д.) и Сизифом? У нас же, вообще говоря, нет линейного порядка бранчей.

Там, где нет линейного порядка, эти отношения в общем случае работают
неправильно.  Но автор решал другую задачу, насколько я понимаю.


-- 
ldv

Re: [devel] распознавание бранча

[Vladimir D. Seleznev]

On Fri, Nov 20, 2020 at 08:52:00PM +0300, Anton Farygin wrote:
> On 20.11.2020 20:47, Dmitry V. Levin wrote:
> > On Fri, Nov 20, 2020 at 07:24:59PM +0300, Mikhail Novosyolov wrote:
> >> 20.11.2020 16:28, Dmitry V. Levin пишет:
> >>> On Fri, Nov 20, 2020 at 01:12:09PM +0300, Anton V. Boyarshinov wrote:
> >>>> В Thu, 19 Nov 2020 19:10:10 +0300, Mikhail Novosyolov пишет:
> >>>>> 19.11.2020 11:33, Anton V. Boyarshinov пишет:
> >>>>>> В Wed, 18 Nov 2020 23:19:51 +0300, Mikhail Novosyolov пишет:
> >>>>>>   
> >>>>>>> А нельзя просто гарантированно пересобирать пакеты при копировании из сизифа в бранч, чтобы в %disstag появлялось p9, а потом на него смотреть?
> >>>>>> Вообще говоря, мы пытаемся решить скорее обратную задачу -- чтоб если
> >>>>>> пакет из Сизифа при сборке в бранч существенно не изменился, то чтоб в
> >>>>>> бранч попадал именно пакет из Сизифа, а не пересобранный.
> >>>>> А зачем?
> >>>> Что бы не плодить во множестве избыточные гигабайты. Для часто
> >>>> собираемых больших пакетов типа ядра разница набегает немаленькая.
> >>>>
> >>>>> И вы уверены, что set-versions настолько крут, что для гарантирования
> >>>> целостности ABI не стоит пересобирать пакет?
> >>>>
> >>>> Вот это и вкладывается в "существенно не изменился". Насколько я знаю,
> >>>> проверяются  не только set-versions.
> >>> Сейчас нет никакого копирования, операция copy - это всего лишь упрощенный
> >>> интерфейс операции сборки, когда нужная редакция исходников определяется
> >>> на стороне сервера.
> >>>
> >>> Единственный случай, когда не происходит сборки - это в момент создания
> >>> бранча.  И это, на самом деле, большая проблема для всех подходов к
> >>> заглядыванию в %disttag/%ubt/whatever каких-либо пакетов, потому что
> >>> в этот момент там записана информация об исходном бранче.
> >> Отсутствие полной пересборки после бранчевания - это просто экономия времени и машинных ресурсов (вряд ли), или чем-то еще обусловлено?
> > Полная пересборка после бранчевания - это концептуально неправильно,
> > по-хорошему, пересобирать нужно всегда, когда результат пересборки
> > меняется, не дожидаясь бранчевания.
> >
> >
> согласен.  не очень сложно выяснить, нужно ли пересобирать пакет.

Очень просто это можно выяснить, используя скрипт rpmindentity из
одноимённого пакета: если он выдаёт одинаковую контрольную сумму для
двух пакетов, значит они существенно одинаковы. Его можно использовать
для проверки необходимости пересборки пакета.

> а ещё если это делать в процессе бранчевания - то у пакетов вырастет 
> buildtime и они из старых станут новыми (соответственно обновятся).

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] пересборка

[Vladimir D. Seleznev]

On Sat, Nov 21, 2020 at 05:56:35AM +0300, Dmitry V. Levin wrote:
> On Sat, Nov 21, 2020 at 05:46:19AM +0300, Vladimir D. Seleznev wrote:
> > On Fri, Nov 20, 2020 at 08:47:05PM +0300, Dmitry V. Levin wrote:
> > > On Fri, Nov 20, 2020 at 07:24:59PM +0300, Mikhail Novosyolov wrote:
> [...]
> > > > Отсутствие полной пересборки после бранчевания - это просто экономия времени и машинных ресурсов (вряд ли), или чем-то еще обусловлено?
> > > 
> > > Полная пересборка после бранчевания - это концептуально неправильно,
> > > по-хорошему, пересобирать нужно всегда, когда результат пересборки
> > > меняется, не дожидаясь бранчевания.
> > 
> > А зачем? Просто пересобранный пакет может внезапно оказаться нерабочим,
> > а кто чинить будет?
> 
> Чем раньше он окажется нерабочим, тем раньше об этом узнают те,
> кто могут починить.  А вообще в нормальном пакете должны быть тесты.

Вторая проблема, более существенная на мой взгляд, то, что сборка многих
пакетов не воспроизводима. Результат каждой пересбоки таких пакетов
будет меняться.

Я предлагаю расширить beehive и функциональность пересборочницы,
сохраняя для каждого пакета список пакетов, входящих в сборочное
окружение, и контрольные суммы результата сборки rpmidentity. И если в
результате следующей итерации пересборки состояние сборочной среды
осталось прежний, а контрольные суммы изменились, значит сборка
невоспроизводима, и публиковать список невоспроизводимых пакетов для
каждой архитектуры, для которой осуществляется пересборка.

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] пересборка

[Anton Farygin]

On 20.11.2020 22:51, Dmitry V. Levin wrote:
> On Fri, Nov 20, 2020 at 09:40:58PM +0300, Mikhail Novosyolov wrote:
>> 20.11.2020 20:52, Anton Farygin пишет:
>>> On 20.11.2020 20:47, Dmitry V. Levin wrote:
>>>> On Fri, Nov 20, 2020 at 07:24:59PM +0300, Mikhail Novosyolov wrote:
> [...]
>>>>> Отсутствие полной пересборки после бранчевания - это просто экономия времени и машинных ресурсов (вряд ли), или чем-то еще обусловлено?
>>>> Полная пересборка после бранчевания - это концептуально неправильно,
>>>> по-хорошему, пересобирать нужно всегда, когда результат пересборки
>>>> меняется, не дожидаясь бранчевания.
>>>>
>>> согласен.  не очень сложно выяснить, нужно ли пересобирать пакет.
>> Недавно в devel@ обсуждался хороший пример, почему это не совсем так: многие пакеты используют лишь заголовки из boost, не линкуясь с ним, все методы определения необходимости пересборки покажут, что пересборка не нужна, но ведь она нужна для уверенности в поддержании пакета в пересобираемом состоянии как минимум. Также могут меняться структуры данных и пр., оставляя внешние символы теми же самыми, такое тоже не отловится существующим инструментарием, гораздо надежнее пересобрать.
> Лучше всего, когда уверенность основывается на знании.
>
> Если все методы определения необходимости пересборки покажут, что
> пересборка не нужна, значит, либо методы неправильные, либо пересборка
> действительно не нужна.
>
> Например, если NT_GNU_BUILD_ID у файла после пересборки с другим boost
> не поменялся, значит, его пересобирать не надо.
>
> Грубо говоря, алгоритм может быть такой:
> 1. определяем все пакеты, у которых поменялась сборочная среда;
> 2. пересобираем все эти пакеты;
> 3. те из них, которые в результате пересборки поменялись, коммитим в репозиторий.

Ла, я ровно это и имел в виду.

Конечно, на практике скорее всего будут случаи, когда мы не сможем 
выявить изменения в результате пересборки, но это будет скорее 
исключением чем правило.

Re: [devel] пересборка -> disttag

[Anton Farygin]

On 21.11.2020 07:09, Vladimir D. Seleznev wrote:
> On Sat, Nov 21, 2020 at 05:56:35AM +0300, Dmitry V. Levin wrote:
>> On Sat, Nov 21, 2020 at 05:46:19AM +0300, Vladimir D. Seleznev wrote:
>>> On Fri, Nov 20, 2020 at 08:47:05PM +0300, Dmitry V. Levin wrote:
>>>> On Fri, Nov 20, 2020 at 07:24:59PM +0300, Mikhail Novosyolov wrote:
>> [...]
>>>>> Отсутствие полной пересборки после бранчевания - это просто экономия времени и машинных ресурсов (вряд ли), или чем-то еще обусловлено?
>>>> Полная пересборка после бранчевания - это концептуально неправильно,
>>>> по-хорошему, пересобирать нужно всегда, когда результат пересборки
>>>> меняется, не дожидаясь бранчевания.
>>> А зачем? Просто пересобранный пакет может внезапно оказаться нерабочим,
>>> а кто чинить будет?
>> Чем раньше он окажется нерабочим, тем раньше об этом узнают те,
>> кто могут починить.  А вообще в нормальном пакете должны быть тесты.
> Вторая проблема, более существенная на мой взгляд, то, что сборка многих
> пакетов не воспроизводима. Результат каждой пересбоки таких пакетов
> будет меняться.
>
> Я предлагаю расширить beehive и функциональность пересборочницы,
> сохраняя для каждого пакета список пакетов, входящих в сборочное
> окружение, и контрольные суммы результата сборки rpmidentity. И если в
> результате следующей итерации пересборки состояние сборочной среды
> осталось прежний, а контрольные суммы изменились, значит сборка
> невоспроизводима, и публиковать список невоспроизводимых пакетов для
> каждой архитектуры, для которой осуществляется пересборка.
>
Лучше, конечно, двигаться последовательно и сначала доделать disttag до 
конца.

Это было бы просто здорово.

Re: [devel] [JT] про команду, %ubt, -xalt и прочее разное

[Anton Farygin]

On 21.11.2020 05:41, Vladimir D. Seleznev wrote:
> On Wed, Nov 18, 2020 at 10:41:50AM +0300, Sergey V Turchin wrote:
>> On Tuesday, 17 November 2020 21:56:18 MSK Michael Shigorin wrote:
>>> On Tue, Nov 17, 2020 at 04:29:58PM +0300, Sergey V Turchin wrote:
>>>> Ещё подгадил админ сборочницы
>>> Ну вообще-то сперва кое-кто единолично нагадил %ubt,
>> Тут, понимаешь ли, лишь буквы похожие.
>> Это совсем другая фича, которая не имеет ничего общего с тем, о чем ты и
>> используется мной до сих пор, т.к. аналог я 1-й раз вижу у Виталия, но у меня
>> покруче, т.к. позволяет не только ==, но и <, <, >= и т.д.
> Как работают эти отношения для сравнения с другими бранчами (t*, c*, и
> т.д.) и Сизифом? У нас же, вообще говоря, нет линейного порядка бранчей.
>
Вообще конечно нет. Линейный порядок бранчей есть всегда, но иногда его 
сложнее вычислить из сложившейся схемы именования веток.

Re: [devel] пересборка -> disttag

[Vladimir D. Seleznev]

On Sat, Nov 21, 2020 at 10:26:07AM +0300, Anton Farygin wrote:
> On 21.11.2020 07:09, Vladimir D. Seleznev wrote:
> > On Sat, Nov 21, 2020 at 05:56:35AM +0300, Dmitry V. Levin wrote:
> >> On Sat, Nov 21, 2020 at 05:46:19AM +0300, Vladimir D. Seleznev wrote:
> >>> On Fri, Nov 20, 2020 at 08:47:05PM +0300, Dmitry V. Levin wrote:
> >>>> On Fri, Nov 20, 2020 at 07:24:59PM +0300, Mikhail Novosyolov wrote:
> >> [...]
> >>>>> Отсутствие полной пересборки после бранчевания - это просто экономия времени и машинных ресурсов (вряд ли), или чем-то еще обусловлено?
> >>>> Полная пересборка после бранчевания - это концептуально неправильно,
> >>>> по-хорошему, пересобирать нужно всегда, когда результат пересборки
> >>>> меняется, не дожидаясь бранчевания.
> >>> А зачем? Просто пересобранный пакет может внезапно оказаться нерабочим,
> >>> а кто чинить будет?
> >> Чем раньше он окажется нерабочим, тем раньше об этом узнают те,
> >> кто могут починить.  А вообще в нормальном пакете должны быть тесты.
> > Вторая проблема, более существенная на мой взгляд, то, что сборка многих
> > пакетов не воспроизводима. Результат каждой пересбоки таких пакетов
> > будет меняться.
> >
> > Я предлагаю расширить beehive и функциональность пересборочницы,
> > сохраняя для каждого пакета список пакетов, входящих в сборочное
> > окружение, и контрольные суммы результата сборки rpmidentity. И если в
> > результате следующей итерации пересборки состояние сборочной среды
> > осталось прежний, а контрольные суммы изменились, значит сборка
> > невоспроизводима, и публиковать список невоспроизводимых пакетов для
> > каждой архитектуры, для которой осуществляется пересборка.
> >
> Лучше, конечно, двигаться последовательно и сначала доделать disttag до 
> конца.

А что недоделано в disttag'е?

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] пересборка -> disttag

[Anton Farygin]

On 21.11.2020 11:14, Vladimir D. Seleznev wrote:
> On Sat, Nov 21, 2020 at 10:26:07AM +0300, Anton Farygin wrote:
>> On 21.11.2020 07:09, Vladimir D. Seleznev wrote:
>>> On Sat, Nov 21, 2020 at 05:56:35AM +0300, Dmitry V. Levin wrote:
>>>> On Sat, Nov 21, 2020 at 05:46:19AM +0300, Vladimir D. Seleznev wrote:
>>>>> On Fri, Nov 20, 2020 at 08:47:05PM +0300, Dmitry V. Levin wrote:
>>>>>> On Fri, Nov 20, 2020 at 07:24:59PM +0300, Mikhail Novosyolov wrote:
>>>> [...]
>>>>>>> Отсутствие полной пересборки после бранчевания - это просто экономия времени и машинных ресурсов (вряд ли), или чем-то еще обусловлено?
>>>>>> Полная пересборка после бранчевания - это концептуально неправильно,
>>>>>> по-хорошему, пересобирать нужно всегда, когда результат пересборки
>>>>>> меняется, не дожидаясь бранчевания.
>>>>> А зачем? Просто пересобранный пакет может внезапно оказаться нерабочим,
>>>>> а кто чинить будет?
>>>> Чем раньше он окажется нерабочим, тем раньше об этом узнают те,
>>>> кто могут починить.  А вообще в нормальном пакете должны быть тесты.
>>> Вторая проблема, более существенная на мой взгляд, то, что сборка многих
>>> пакетов не воспроизводима. Результат каждой пересбоки таких пакетов
>>> будет меняться.
>>>
>>> Я предлагаю расширить beehive и функциональность пересборочницы,
>>> сохраняя для каждого пакета список пакетов, входящих в сборочное
>>> окружение, и контрольные суммы результата сборки rpmidentity. И если в
>>> результате следующей итерации пересборки состояние сборочной среды
>>> осталось прежний, а контрольные суммы изменились, значит сборка
>>> невоспроизводима, и публиковать список невоспроизводимых пакетов для
>>> каждой архитектуры, для которой осуществляется пересборка.
>>>
>> Лучше, конечно, двигаться последовательно и сначала доделать disttag до
>> конца.
> А что недоделано в disttag'е?
>
Решить проблему с обновлением с p9 до Sisyphus:

https://bugzilla.altlinux.org/show_bug.cgi?id=37192

https://bugzilla.altlinux.org/show_bug.cgi?id=35529

Re: [devel] пересборка -> disttag

[Dmitry V. Levin]

On Sat, Nov 21, 2020 at 11:14:06AM +0300, Vladimir D. Seleznev wrote:
> On Sat, Nov 21, 2020 at 10:26:07AM +0300, Anton Farygin wrote:
> > On 21.11.2020 07:09, Vladimir D. Seleznev wrote:
> > > On Sat, Nov 21, 2020 at 05:56:35AM +0300, Dmitry V. Levin wrote:
> > >> On Sat, Nov 21, 2020 at 05:46:19AM +0300, Vladimir D. Seleznev wrote:
> > >>> On Fri, Nov 20, 2020 at 08:47:05PM +0300, Dmitry V. Levin wrote:
> > >>>> On Fri, Nov 20, 2020 at 07:24:59PM +0300, Mikhail Novosyolov wrote:
> > >> [...]
> > >>>>> Отсутствие полной пересборки после бранчевания - это просто экономия времени и машинных ресурсов (вряд ли), или чем-то еще обусловлено?
> > >>>> Полная пересборка после бранчевания - это концептуально неправильно,
> > >>>> по-хорошему, пересобирать нужно всегда, когда результат пересборки
> > >>>> меняется, не дожидаясь бранчевания.
> > >>> А зачем? Просто пересобранный пакет может внезапно оказаться нерабочим,
> > >>> а кто чинить будет?
> > >> Чем раньше он окажется нерабочим, тем раньше об этом узнают те,
> > >> кто могут починить.  А вообще в нормальном пакете должны быть тесты.
> > > Вторая проблема, более существенная на мой взгляд, то, что сборка многих
> > > пакетов не воспроизводима. Результат каждой пересбоки таких пакетов
> > > будет меняться.
> > >
> > > Я предлагаю расширить beehive и функциональность пересборочницы,
> > > сохраняя для каждого пакета список пакетов, входящих в сборочное
> > > окружение, и контрольные суммы результата сборки rpmidentity. И если в
> > > результате следующей итерации пересборки состояние сборочной среды
> > > осталось прежний, а контрольные суммы изменились, значит сборка
> > > невоспроизводима, и публиковать список невоспроизводимых пакетов для
> > > каждой архитектуры, для которой осуществляется пересборка.
> > >
> > Лучше, конечно, двигаться последовательно и сначала доделать disttag до 
> > конца.
> 
> А что недоделано в disttag'е?

Как минимум это было обещано год назад, но не сделано:
https://bugzilla.altlinux.org/show_bug.cgi?id=37192#c9


-- 
ldv

Re: [devel] распознавание бранча -> %_priority_distbranch

[Dmitry V. Levin]

On Fri, Nov 20, 2020 at 06:20:27PM +0300, Dmitry V. Levin wrote:
> On Fri, Nov 20, 2020 at 06:12:02PM +0300, Anton Farygin wrote:
[...]
> > Ну и в продолжение темы - может быть сделать общесистемный конфиг в 
> > отдельном пакете, в котором будет собственно этот самый branch в том или 
> > ином виде, таким образом, что бы его можно было распознавать и 
> > использовать в спеках.
> 
> Тогда этот пакет должен быть первым, который собирается в новый бранч.
> Сейчас таким пакетом является altlinux-release-$branch.

Если мы идём этим путём, то в каждом репозитории должен остаться ровно
один провайдер altlinux-release.  На данный момент это, мягко выражаясь,
не совсем так.  Например, в Сизифе

$ apt-cache showpkg altlinux-release 
Package: altlinux-release
Versions: 

Reverse Depends: 
  branding-xalt-kworkstation-release,altlinux-release
  branding-simply-linux-release,altlinux-release
  branding-alt-workstation-release,altlinux-release
  branding-alt-spworkstation-release,altlinux-release
  branding-alt-spserver-release,altlinux-release
  branding-alt-sisyphus-release,altlinux-release
  branding-alt-server-v-release,altlinux-release
  branding-alt-server-release,altlinux-release
  basesystem-ve,altlinux-release
  basesystem,altlinux-release
  altlinux-release-sisyphus,altlinux-release
  altlinux-release-p8,altlinux-release
  altlinux-release-icarus,altlinux-release
Dependencies: 
Provides: 
Reverse Provides: 
branding-xalt-kworkstation-release 9.1.1-alt1:sisyphus+259371.200.2.1@1602078230
branding-simply-linux-release 9.0-alt1:sisyphus+248419.100.1.1@1585055051
branding-alt-workstation-release 9.1-alt1:sisyphus+255027.100.1.1@1594984242
branding-alt-spworkstation-release 8.2-alt5:sisyphus+258637.100.1.1@1601019102
branding-alt-spserver-release 8.2-alt3:sisyphus+258641.100.1.1@1601020088
branding-alt-sisyphus-release 20191026-alt1:sisyphus+239769.100.1.1@1572078254
branding-alt-server-v-release 9.1-alt3:sisyphus+259907.100.1.1@1602693586
branding-alt-server-release 9.1-alt3:sisyphus+254708.100.1.1@1594294890
altlinux-release-sisyphus 20081222-alt1@1229985182
altlinux-release-p8 20160414-alt1@1460649569
altlinux-release-icarus 20160328-alt1@1460113502


-- 
ldv

Re: [devel] сборка пакета, опирающаяся на свойства бранча

[Vitaly Lipatov]

Антон Мидюков писал 20.11.20 22:26:
...
> А в чём проблема сейчас такой пакет сделать и собрать во все бранчи?
> 
> Кому надо, подключит в спеке
> 
> BuildRequires(pre): rpm-macros-branch-config
Прежде чем что-то делать, лучше обсудить, узнать, какие есть мнения на 
этот счёт.
И согласовать с главным архитектором.

-- 
С уважением,
Виталий Липатов,
ALT Linux Team

Re: [devel] распознавание бранча -> %_priority_distbranch

[Anton Farygin]

On 21.11.2020 17:57, Dmitry V. Levin wrote:
> On Fri, Nov 20, 2020 at 06:20:27PM +0300, Dmitry V. Levin wrote:
>> On Fri, Nov 20, 2020 at 06:12:02PM +0300, Anton Farygin wrote:
> [...]
>>> Ну и в продолжение темы - может быть сделать общесистемный конфиг в
>>> отдельном пакете, в котором будет собственно этот самый branch в том или
>>> ином виде, таким образом, что бы его можно было распознавать и
>>> использовать в спеках.
>> Тогда этот пакет должен быть первым, который собирается в новый бранч.
>> Сейчас таким пакетом является altlinux-release-$branch.
> Если мы идём этим путём, то в каждом репозитории должен остаться ровно
> один провайдер altlinux-release.  На данный момент это, мягко выражаясь,
> не совсем так.  Например, в Сизифе
>
Да, концепцию alttlinux-release тоже, наверное, можно пересмотреть.

Re: [devel] распознавание бранча

[Anton V. Boyarshinov]

В Fri, 20 Nov 2020 16:28:24 +0300
"Dmitry V. Levin" <ldv@altlinux.org> пишет:

> >   
> > > И вы уверены, что set-versions настолько крут, что для гарантирования  
> > целостности ABI не стоит пересобирать пакет?
> > 
> > Вот это и вкладывается в "существенно не изменился". Насколько я знаю,
> > проверяются  не только set-versions.  
> 
> Сейчас нет никакого копирования, операция copy - это всего лишь упрощенный
> интерфейс операции сборки, когда нужная редакция исходников определяется
> на стороне сервера.

Насколько я знаю, работы по оптимизации хранения путём сравнения
результатов этой сборки с имеющимся пакетом ведутся или велись. Не
помню, закончилось ли чем-то.

Re: [devel] [JT] про команду, %ubt, -xalt и прочее разное

[Sergey V Turchin]

On Friday, 20 November 2020 19:17:00 MSK Vitaly Lipatov wrote:
> Sergey V Turchin писал 19.11.20 10:51:
> ...
> 
> > Ну, вот, мой без костыля теперь не получается использовать, т.к.
> > сборочница
> > предательски и абсолютно незаслуженно убивает значение макроса %ubt_id.
> 
> Ах вот что... :(
> 
> > Если ты у себя сделаешь значения _distro_version пригодные для
> > сравнения, то
> > сможешь пользоваться макросами сравнения версий
> > http://bugs.altlinux.org/6010
> 
> Спасибо за напоминание!
> У меня возникло большое подозрение в монотонности роста названия бранча,
> особенно после того, как назвали сертифицированный бранч p9.
С ним отдельная история. Он вроде как p9, но, видимо, будет косить под p8, 
т.е. M89C, что ли.

-- 
Regards, Sergey.

Re: [devel] [JT] про команду, %ubt, -xalt и прочее разное

[Sergey V Turchin]

On Saturday, 21 November 2020 05:41:56 MSK Vladimir D wrote:
> On Wed, Nov 18, 2020 at 10:41:50AM +0300, Sergey V Turchin wrote:
> > On Tuesday, 17 November 2020 21:56:18 MSK Michael Shigorin wrote:
> > > On Tue, Nov 17, 2020 at 04:29:58PM +0300, Sergey V Turchin wrote:
> > > > Ещё подгадил админ сборочницы
> > > 
> > > Ну вообще-то сперва кое-кто единолично нагадил %ubt,
> > 
> > Тут, понимаешь ли, лишь буквы похожие.
> > Это совсем другая фича, которая не имеет ничего общего с тем, о чем ты и
> > используется мной до сих пор, т.к. аналог я 1-й раз вижу у Виталия, но у
> > меня покруче, т.к. позволяет не только ==, но и <, <, >= и т.д.
> 
> Как работают эти отношения для сравнения с другими бранчами (t*, c*, и
> т.д.) и Сизифом? У нас же, вообще говоря, нет линейного порядка бранчей.
Пофиг, т.к.,
%if_ver_gteq %ubt_id M80
работает в любом случае.

-- 
Regards, Sergey.

Re: [devel] распознавание бранча

[Vladimir D. Seleznev]

On Mon, Nov 23, 2020 at 03:26:51PM +0300, Anton V. Boyarshinov wrote:
> В Fri, 20 Nov 2020 16:28:24 +0300
> "Dmitry V. Levin" <ldv@altlinux.org> пишет:
> 
> > >   
> > > > И вы уверены, что set-versions настолько крут, что для гарантирования  
> > > целостности ABI не стоит пересобирать пакет?
> > > 
> > > Вот это и вкладывается в "существенно не изменился". Насколько я знаю,
> > > проверяются  не только set-versions.  
> > 
> > Сейчас нет никакого копирования, операция copy - это всего лишь упрощенный
> > интерфейс операции сборки, когда нужная редакция исходников определяется
> > на стороне сервера.
> 
> Насколько я знаю, работы по оптимизации хранения путём сравнения
> результатов этой сборки с имеющимся пакетом ведутся или велись. Не
> помню, закончилось ли чем-то.

Не закончилось, но застопорилось.

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] пересборка

[Mikhail Novosyolov]

20.11.2020 22:51, Dmitry V. Levin пишет:
> On Fri, Nov 20, 2020 at 09:40:58PM +0300, Mikhail Novosyolov wrote:
>> 20.11.2020 20:52, Anton Farygin пишет:
>>> On 20.11.2020 20:47, Dmitry V. Levin wrote:
>>>> On Fri, Nov 20, 2020 at 07:24:59PM +0300, Mikhail Novosyolov wrote:
> [...]
>>>>> Отсутствие полной пересборки после бранчевания - это просто экономия времени и машинных ресурсов (вряд ли), или чем-то еще обусловлено?
>>>> Полная пересборка после бранчевания - это концептуально неправильно,
>>>> по-хорошему, пересобирать нужно всегда, когда результат пересборки
>>>> меняется, не дожидаясь бранчевания.
>>>>
>>> согласен.  не очень сложно выяснить, нужно ли пересобирать пакет.
>> Недавно в devel@ обсуждался хороший пример, почему это не совсем так: многие пакеты используют лишь заголовки из boost, не линкуясь с ним, все методы определения необходимости пересборки покажут, что пересборка не нужна, но ведь она нужна для уверенности в поддержании пакета в пересобираемом состоянии как минимум. Также могут меняться структуры данных и пр., оставляя внешние символы теми же самыми, такое тоже не отловится существующим инструментарием, гораздо надежнее пересобрать.
> Лучше всего, когда уверенность основывается на знании.
>
> Если все методы определения необходимости пересборки покажут, что
> пересборка не нужна, значит, либо методы неправильные, либо пересборка
> действительно не нужна.
>
> Например, если NT_GNU_BUILD_ID у файла после пересборки с другим boost
> не поменялся, значит, его пересобирать не надо.
>
> Грубо говоря, алгоритм может быть такой:
> 1. определяем все пакеты, у которых поменялась сборочная среда;

Думаете, будет много пакетов, у которых N, E, V, R, DistTag, Buildtime всех пакетов из сборочного окружения не изменились? Ведь даже rpm-build должен быть строго одинаковым, а если в одном бранче он начинает отличаться от другого, то всё. Или обсуждаемый в соседней ветке altlinux-release.

Мне на глаз (пальцем в небо) кажется, что таких пакетов будет очень мало.

Можно проверять одинаковость раскрытия спека (rpmspec --parse), в т.ч. формируемых макросами скриптлетов.

> 2. пересобираем все эти пакеты;
> 3. те из них, которые в результате пересборки поменялись, коммитим в репозиторий.
>
>