[devel] Сборка новой версии после использования epoch

[devel] Сборка новой версии после использования epoch

[Pavel Vainerman]

Добрый вечер.

Подскажите пожалуйста.
Есть текущая версия библиотеки собранная с epoch (до меня).
Версия 1:4.0.1-alt2_17

Если я хочу собрать новую версию библиотеки 6.4.5 могу ли я удалить
epoch или это уже навсегда?

И второй вопрос. Текущая версия недавно была собрана из src.rpm, а я
хочу вернуть сборки из git. Нужно ли при этом делать какие-то доп. движения?

Речь о пакете libpqxx

https://packages.altlinux.org/ru/sisyphus/srpms/libpqxx

-- 
Pavel Vainerman
www.etersoft.ru

Re: [devel] Сборка новой версии после использования epoch

[Nikolai Kostrigin]

29.01.2020 0:02, Pavel Vainerman пишет:
> Добрый вечер.
>
> Подскажите пожалуйста.
> Есть текущая версия библиотеки собранная с epoch (до меня).
> Версия 1:4.0.1-alt2_17
>
> Если я хочу собрать новую версию библиотеки 6.4.5 могу ли я удалить
> epoch или это уже навсегда?
Это навсегда, пока имя пакета неизменно, чтобы не сломать "вес" версии
для apt при обновлении
> И второй вопрос. Текущая версия недавно была собрана из src.rpm, а я
> хочу вернуть сборки из git. Нужно ли при этом делать какие-то доп. движения?
>
> Речь о пакете libpqxx
>
> https://packages.altlinux.org/ru/sisyphus/srpms/libpqxx
Насколько я знаю, пакет ранее собиравшийся из src.rpm при сборке в gears
автоматически переезжает в gears.
Однако, если для Вас эта сборка одократная акция, рекомендую
посоветоваться с viy@, т.к. в дальнейшем ему такой переезд может быть
неудобен.

-- 
Best regards,
Nikolai Kostrigin

Re: [devel] Сборка новой версии после использования epoch

[Pavel Vainerman]

>> Если я хочу собрать новую версию библиотеки 6.4.5 могу ли я удалить
>> epoch или это уже навсегда?
> Это навсегда, пока имя пакета неизменно, чтобы не сломать "вес" версии
> для apt при обновлении

  Понял спасибо.


>> И второй вопрос. Текущая версия недавно была собрана из src.rpm, а я
>> хочу вернуть сборки из git. Нужно ли при этом делать какие-то доп.
движения?
> Насколько я знаю, пакет ранее собиравшийся из src.rpm при сборке в gears
> автоматически переезжает в gears.
> Однако, если для Вас эта сборка одократная акция, рекомендую
> посоветоваться с viy@, т.к. в дальнейшем ему такой переезд может быть
> неудобен.

  Я пока не определился. Новая версия требует c++17 (как раз мне
понадобилось в проекте). А я так понимаю ещё многие библиотеки ещё не
готовы к с++17. С другой стороны от libpqxx сейчас зависит только один
мой пакет )


-- 
Pavel Vainerman
www.etersoft.ru

Re: [devel] Сборка новой версии после использования epoch

[Alexey V. Vissarionov]

On 2020-01-29 02:15:37 +0300, Pavel Vainerman wrote:
 >>> Если я хочу собрать новую версию библиотеки 6.4.5 могу ли я
 >>> удалить epoch или это уже навсегда?
 > Я пока не определился. Новая версия требует c++17 (как раз мне
 > понадобилось в проекте). А я так понимаю ещё многие библиотеки
 > ещё не готовы к с++17. С другой стороны от libpqxx сейчас зависит
 > только один мой пакет )

Тогда возможен такой вариант: удалить оба пакета и собрать их уже
без epoch. Да, поломается обновление, но для двух пакетов это не
критично.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] Сборка новой версии после использования epoch

[Dmitry V. Levin]

On Wed, Jan 29, 2020 at 11:24:50AM +0300, Alexey V. Vissarionov wrote:
> On 2020-01-29 02:15:37 +0300, Pavel Vainerman wrote:
>  >>> Если я хочу собрать новую версию библиотеки 6.4.5 могу ли я
>  >>> удалить epoch или это уже навсегда?
>  > Я пока не определился. Новая версия требует c++17 (как раз мне
>  > понадобилось в проекте). А я так понимаю ещё многие библиотеки
>  > ещё не готовы к с++17. С другой стороны от libpqxx сейчас зависит
>  > только один мой пакет )
> 
> Тогда возможен такой вариант: удалить оба пакета и собрать их уже
> без epoch. Да, поломается обновление, но для двух пакетов это не
> критично.

Скоро в сборочнице будет проверка, которая это жульничество запретит.


-- 
ldv

Re: [devel] Сборка новой версии после использования epoch

[Alexey V. Vissarionov]

On 2020-01-29 12:35:22 +0300, Dmitry V. Levin wrote:
 > On Wed, Jan 29, 2020 at 11:24:50AM +0300, Alexey V. Vissarionov wrote:
 >> On 2020-01-29 02:15:37 +0300, Pavel Vainerman wrote:
 >>>>> Если я хочу собрать новую версию библиотеки 6.4.5 могу ли я
 >>>>> удалить epoch или это уже навсегда?
 >>> Я пока не определился. Новая версия требует c++17 (как раз мне
 >>> понадобилось в проекте). А я так понимаю ещё многие библиотеки
 >>> ещё не готовы к с++17. С другой стороны от libpqxx сейчас зависит
 >>> только один мой пакет )
 >> Тогда возможен такой вариант: удалить оба пакета и собрать
 >> их уже без epoch. Да, поломается обновление, но для двух пакетов
 >> это не критично.
 > Скоро в сборочнице будет проверка, которая это жульничество
 > запретит.

А смысл? Скорее, наоборот, нужно предусмотреть штатный способ для
восстановления после серьезных fuqup'ов.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] Сборка новой версии после использования epoch

[Anton Farygin]

On 29.01.2020 12:38, Alexey V. Vissarionov wrote:
> On 2020-01-29 12:35:22 +0300, Dmitry V. Levin wrote:
>   > On Wed, Jan 29, 2020 at 11:24:50AM +0300, Alexey V. Vissarionov wrote:
>   >> On 2020-01-29 02:15:37 +0300, Pavel Vainerman wrote:
>   >>>>> Если я хочу собрать новую версию библиотеки 6.4.5 могу ли я
>   >>>>> удалить epoch или это уже навсегда?
>   >>> Я пока не определился. Новая версия требует c++17 (как раз мне
>   >>> понадобилось в проекте). А я так понимаю ещё многие библиотеки
>   >>> ещё не готовы к с++17. С другой стороны от libpqxx сейчас зависит
>   >>> только один мой пакет )
>   >> Тогда возможен такой вариант: удалить оба пакета и собрать
>   >> их уже без epoch. Да, поломается обновление, но для двух пакетов
>   >> это не критично.
>   > Скоро в сборочнице будет проверка, которая это жульничество
>   > запретит.
>
> А смысл? Скорее, наоборот, нужно предусмотреть штатный способ для
> восстановления после серьезных fuqup'ов.
>
>
Смысл в том, что таким образом вы ломаете обновление, а это критично всегда.

Re: [devel] Сборка новой версии после использования epoch

[Vladimir D. Seleznev]

On Wed, Jan 29, 2020 at 12:41:45PM +0300, Anton Farygin wrote:
> On 29.01.2020 12:38, Alexey V. Vissarionov wrote:
> > On 2020-01-29 12:35:22 +0300, Dmitry V. Levin wrote:
> >   > On Wed, Jan 29, 2020 at 11:24:50AM +0300, Alexey V. Vissarionov wrote:
> >   >> On 2020-01-29 02:15:37 +0300, Pavel Vainerman wrote:
> >   >>>>> Если я хочу собрать новую версию библиотеки 6.4.5 могу ли я
> >   >>>>> удалить epoch или это уже навсегда?
> >   >>> Я пока не определился. Новая версия требует c++17 (как раз мне
> >   >>> понадобилось в проекте). А я так понимаю ещё многие библиотеки
> >   >>> ещё не готовы к с++17. С другой стороны от libpqxx сейчас зависит
> >   >>> только один мой пакет )
> >   >> Тогда возможен такой вариант: удалить оба пакета и собрать
> >   >> их уже без epoch. Да, поломается обновление, но для двух пакетов
> >   >> это не критично.
> >   > Скоро в сборочнице будет проверка, которая это жульничество
> >   > запретит.
> >
> > А смысл? Скорее, наоборот, нужно предусмотреть штатный способ для
> > восстановления после серьезных fuqup'ов.
> >
> >
> Смысл в том, что таким образом вы ломаете обновление, а это критично всегда.

Давний недуг сопровождающих: эпохофобия.

Re: [devel] Сборка новой версии после использования epoch

[Sergey V Turchin]

On Wednesday, 29 January 2020 21:05:25 MSK Vladimir D wrote:

[...]
> Давний недуг сопровождающих: эпохофобия.
Это нормальное явление, т.к. при его наличии приходится думать, в каких 
provides/requires его использовать, а в каких недопустимо. Особенно могут 
пострадать сторонние пакеты.

-- 
Regards, Sergey.

Re: [devel] Сборка новой версии после использования epoch

[Nikolai Kostrigin]

30.01.2020 10:29, Sergey V Turchin пишет:
> On Wednesday, 29 January 2020 21:05:25 MSK Vladimir D wrote:
>
> [...]
>> Давний недуг сопровождающих: эпохофобия.
> Это нормальное явление, т.к. при его наличии приходится думать, в каких 
>   его использовать, а в каких недопустимо. Особенно могут 
> пострадать сторонние пакеты.
А можно поподробнее? Не знал, что эпоха налагает какие-то ограничения на
работоспособность  provides/requires

-- 
Best regards,
Nikolai Kostrigin

Re: [devel] Сборка новой версии после использования epoch

[Sergey V Turchin]

On Thursday, 30 January 2020 10:32:43 MSK Nikolai Kostrigin wrote:
> 30.01.2020 10:29, Sergey V Turchin пишет:
> > On Wednesday, 29 January 2020 21:05:25 MSK Vladimir D wrote:
> > 
> > [...]
> > 
> >> Давний недуг сопровождающих: эпохофобия.
> > 
> > Это нормальное явление, т.к. при его наличии приходится думать, в каких
> > 
> >   его использовать, а в каких недопустимо. Особенно могут
> > 
> > пострадать сторонние пакеты.
> 
> А можно поподробнее? Не знал, что эпоха налагает какие-то ограничения на
> работоспособность  provides/requires
Например
Provides: qt-assistant 4.8.7 (в пакете qt4-assistant)
Provides: qt-assistant 5.12.5 (в пакете qt5-tools-assistant)
Requires: qt-assistant (в другом пакете ранее)

При добавлении Epoch в qt4-assistant по зависимости станет вытаскиваться 
совсем другой пакет по умолчанию.

-- 
Regards, Sergey.

Re: [devel] Сборка новой версии после использования epoch

[Sergey V Turchin]

On Thursday, 30 January 2020 10:52:50 MSK Sergey V wrote:
> On Thursday, 30 January 2020 10:32:43 MSK Nikolai Kostrigin wrote:
> > 30.01.2020 10:29, Sergey V Turchin пишет:
> > > On Wednesday, 29 January 2020 21:05:25 MSK Vladimir D wrote:
> > > 
> > > [...]
> > > 
> > >> Давний недуг сопровождающих: эпохофобия.
> > > 
> > > Это нормальное явление, т.к. при его наличии приходится думать, в каких
> > > 
> > >   его использовать, а в каких недопустимо. Особенно могут
> > > 
> > > пострадать сторонние пакеты.
> > 
> > А можно поподробнее? Не знал, что эпоха налагает какие-то ограничения на
> > работоспособность  provides/requires
> 
> Например
> Provides: qt-assistant 4.8.7 (в пакете qt4-assistant)
> Provides: qt-assistant 5.12.5 (в пакете qt5-tools-assistant)
> Requires: qt-assistant (в другом пакете ранее)
> 
> При добавлении Epoch в qt4-assistant по зависимости станет вытаскиваться
> совсем другой пакет по умолчанию.
Причём, даже если было
Requires: qt-assistant >= 5.0

-- 
Regards, Sergey.

Re: [devel] Сборка новой версии после использования epoch

[Nikolai Kostrigin]

30.01.2020 10:55, Sergey V Turchin пишет:
> On Thursday, 30 January 2020 10:52:50 MSK Sergey V wrote:
>> On Thursday, 30 January 2020 10:32:43 MSK Nikolai Kostrigin wrote:
>>> 30.01.2020 10:29, Sergey V Turchin пишет:
>>>> On Wednesday, 29 January 2020 21:05:25 MSK Vladimir D wrote:
>>>>
>>>> [...]
>>>>
>>>>> Давний недуг сопровождающих: эпохофобия.
>>>> Это нормальное явление, т.к. при его наличии приходится думать, в каких
>>>>
>>>>   его использовать, а в каких недопустимо. Особенно могут
>>>>
>>>> пострадать сторонние пакеты.
>>> А можно поподробнее? Не знал, что эпоха налагает какие-то ограничения на
>>> работоспособность  provides/requires
>> Например
>> Provides: qt-assistant 4.8.7 (в пакете qt4-assistant)
>> Provides: qt-assistant 5.12.5 (в пакете qt5-tools-assistant)
>> Requires: qt-assistant (в другом пакете ранее)
>>
>> При добавлении Epoch в qt4-assistant по зависимости станет вытаскиваться
>> совсем другой пакет по умолчанию.
> Причём, даже если было
> Requires: qt-assistant >= 5.0
>
Т.е вылечить эту ситуацию можно будет только добавлением эпохи ещё и в
qt-assistant 5.12.5 ?

 -- 
Best regards,
Nikolai Kostrigin

Re: [devel] Сборка новой версии после использования epoch

[Sergey V Turchin]

On Thursday, 30 January 2020 10:58:00 MSK Nikolai Kostrigin wrote:

[...]
> >>> А можно поподробнее? Не знал, что эпоха налагает какие-то ограничения на
> >>> работоспособность  provides/requires
> >> 
> >> Например
> >> Provides: qt-assistant 4.8.7 (в пакете qt4-assistant)
> >> Provides: qt-assistant 5.12.5 (в пакете qt5-tools-assistant)
> >> Requires: qt-assistant (в другом пакете ранее)
> >> 
> >> При добавлении Epoch в qt4-assistant по зависимости станет вытаскиваться
> >> совсем другой пакет по умолчанию.
> > 
> > Причём, даже если было
> > Requires: qt-assistant >= 5.0
> 
> Т.е вылечить эту ситуацию можно будет только добавлением эпохи ещё и в
> qt-assistant 5.12.5 ?
Нет, ведь кроме него может быть ещё 38 разных qt-assistant. В том числе, 
которые могут стоять у пользователя и уже отсутствовать в репозитории.
Лечить нужно qt4-assistant, выставив Provides без Epoch.

Так же, могут быть ситуации, где, наоборот, Epoch необходим.
Obsoletes так же могут поломаться.

Т.е. переименования пакетов и добавление Epoch лучше всего избегать.

-- 
Regards, Sergey.

Re: [devel] Сборка новой версии после использования epoch

[Mikhail Novosyolov]

30.01.2020 10:32, Nikolai Kostrigin пишет:
> 30.01.2020 10:29, Sergey V Turchin пишет:
>> On Wednesday, 29 January 2020 21:05:25 MSK Vladimir D wrote:
>>
>> [...]
>>> Давний недуг сопровождающих: эпохофобия.
>> Это нормальное явление, т.к. при его наличии приходится думать, в каких 
>>   его использовать, а в каких недопустимо. Особенно могут 
>> пострадать сторонние пакеты.
> А можно поподробнее? Не знал, что эпоха налагает какие-то ограничения на
> работоспособность  provides/requires

Можно запросто ошибиться, например, пакет p2 требует p1 >= текущая версия, пишем:

Requires: p1 >= V-R

когда как надо

Requires: p1 >= E:V-R

и никто не заметит, что даже более старая версия с поднятой эпохой попадает под ">=", а сборочница такое не поймает.

Особенно актуально для Requires(pre).

Re: [devel] Сборка новой версии после использования epoch

[Alexey Tourbin]

On Sun, Feb 9, 2020 at 2:58 PM Mikhail Novosyolov
<mikhailnov@altlinux.org> wrote:
> > А можно поподробнее? Не знал, что эпоха налагает какие-то ограничения на
> > работоспособность  provides/requires
>
> Можно запросто ошибиться, например, пакет p2 требует p1 >= текущая версия, пишем:
>
> Requires: p1 >= V-R
>
> когда как надо
>
> Requires: p1 >= E:V-R
>
> и никто не заметит, что даже более старая версия с поднятой эпохой попадает под ">=", а сборочница такое не поймает.

Племя младое незнакомое. Пишите без Epoch, должно работать как надо.

Re: [devel] Сборка новой версии после использования epoch

[Ivan Zakharyaschev]

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

Hello!

On Sun, 9 Feb 2020, Alexey Tourbin wrote:

> On Sun, Feb 9, 2020 at 2:58 PM Mikhail Novosyolov
> <mikhailnov@altlinux.org> wrote:
> > > А можно поподробнее? Не знал, что эпоха налагает какие-то ограничения на
> > > работоспособность  provides/requires
> >
> > Можно запросто ошибиться, например, пакет p2 требует p1 >= текущая версия, пишем:
> >
> > Requires: p1 >= V-R
> >
> > когда как надо
> >
> > Requires: p1 >= E:V-R
> >
> > и никто не заметит, что даже более старая версия с поднятой эпохой попадает под ">=", а сборочница такое не поймает.

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

> Племя младое незнакомое. Пишите без Epoch, должно работать как надо.

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

Например, у пакета p1 в истории были сборки:

A: 1-alt1
B: 1-alt2
C: 1-alt3
D: 2-alt1
E: 2-alt2
F: 2-alt3
G: 1:1-alt1
H: 1:1-alt2
I: 1:1-alt3
J: 1:2-alt1
K: 1:2-alt2
L: 1:2-alt3

Когда текущим релизом было E, написали где-то Requires: p1 >= 2-alt2.

Хочется ли, чтобы G, H, I могли удволетворить этот Requires?

Я так понял Ваши слова, что не хочется. (Правильно?) Т.е. не хочется, 
чтобы более старая версия (upstream-а) могла удволетворить эту 
завиисимость, пусть и с повышенной эпохой в пакете?


Но если сравнивать тройки E;V-R и написать Requires: p1 >= 0:2-alt2, то уж 
точно его удовлетворят все релизы после E:
E, F, G, H, I, J, K, L,
а это то, чего не хочется.

Хорошо бы уметь просить сравнивать только версию, без эпохи. Если это 
будет работать при написании Requires: p1 >= 2-alt2, то такую зависимость 
удволетворять будут только:
E, F, K, L.

Это ближе к тому, чего хочется?

Вопрос для всех на подумать:

Во всей этой истории я не очень понимаю, какое значение может играть номер 
релиза после версии. Мне кажется, что исключать J (1:2-alt1) из набора 
удовлетворяющих зависимость в последнем примере как-то странно, ведь этот 
alt2 может никак не быть связан с alt2 в E (2-alt2).

Не правильнее было бы считать, что есть два разумных формата Requires:

1) Requires: p1 >= 0:2-alt2 (уже разобран, удволетворяют все от E до L)

2) Requires: p1 >= 2

чтобы его удовлетворяли D, E, F, J, K, L?

А Requires: p1 >= 2-alt2 считать недостаточно ясным: что хотел автор? 
Может быть, раз он указал точный релиз, он хотел сравнения как в 1)?

Технически так написать возможно и оно будет, наверное, 
проинтерпретировано, как я уже сказал (удовлтетворять будут E, F, K, L). 
Но стоит ли рекомендовать эту неясную форму?

В свете записанных мной здесь соображений мне кажется, что рекомендовать 
лучше либо 1), либо 2), а Requires: p1 >= 2-alt2 не рекомендовать. Что 
думаете?

-- 
Best regards,
Ivan

Re: [devel] Сборка новой версии после использования epoch

[Ivan Zakharyaschev]

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


On Mon, 10 Feb 2020, Ivan Zakharyaschev wrote:

> Например, у пакета p1 в истории были сборки:
> 
> A: 1-alt1
> B: 1-alt2
> C: 1-alt3
> D: 2-alt1
> E: 2-alt2
> F: 2-alt3
> G: 1:1-alt1
> H: 1:1-alt2
> I: 1:1-alt3
> J: 1:2-alt1
> K: 1:2-alt2
> L: 1:2-alt3

> Не правильнее было бы считать, что есть два разумных формата Requires:
> 
> 1) Requires: p1 >= 0:2-alt2 (уже разобран, удволетворяют все от E до L)
> 
> 2) Requires: p1 >= 2
> 
> чтобы его удовлетворяли D, E, F, J, K, L?
> 
> А Requires: p1 >= 2-alt2 считать недостаточно ясным: что хотел автор? 
> Может быть, раз он указал точный релиз, он хотел сравнения как в 1)?
> 
> Технически так написать возможно и оно будет, наверное, 
> проинтерпретировано, как я уже сказал (удовлтетворять будут E, F, K, L). 
> Но стоит ли рекомендовать эту неясную форму?
> 
> В свете записанных мной здесь соображений мне кажется, что рекомендовать 
> лучше либо 1), либо 2), а Requires: p1 >= 2-alt2 не рекомендовать. Что 
> думаете?

Вот реальное поведение rpm в p8 по отношению к:

1) Requires с указанием E:V-R
2) Requires с указанием только V
3) Requires с указанием V-R

(На основе лога
http://git.altlinux.org/tasks/archive/done/_237/243303/build/300/x86_64/log .)

########################################
# 1) Requires с указанием E:V-R
########################################

$ < /tasks/archive/done/_$(( 243303 / 1024 ))/243303/build/300/x86_64/log sed -re '/^TESTING / i TESTED' |sed -nre '\|^\+ \./makeme\.sh.*1$|,\|^\+ \./makeme\.sh.*clean$| { /TESTING .*_with_reqGreaterEpoch$/,/TESTED/ p; }'
TESTING installable_dummy2_with_reqGreaterEpoch
make[1]: Entering directory `/usr/src/RPM/BUILD/rpminstall-tests-1.1.3'
mkdir -p SPECS
cat >SPECS/reqGreaterEpoch.spec <<-'EOF'
Name: reqGreaterEpoch

Version: 1
Release: alt1
License: dummy license
Group: Other
Summary: dummy summy

BuildArch: noarch


AutoReq: no
AutoProv: no
Requires: dummy > 0:1-alt1

%description
dummy desc

%install

mkdir -p %buildroot`dirname /etc/rpminstall-tests/%name`
# Fill it with some unique value; each time new.
# (We rely on the fact that %%buildroot comes from mktemp.)
echo %buildroot >%buildroot/etc/rpminstall-tests/%name


%files
/etc/rpminstall-tests/%name
EOF
. /usr/lib/rpm/tmpdir.sh
rpmbuild --define "_tmppath $tmpdir" --define "_builddir $tmpdir/BUILD" --define "_topdir /usr/src/RPM/BUILD/rpminstall-tests-1.1.3" --define '_sourcedir /usr/src/RPM/BUILD/rpminstall-tests-1.1.3' --define '_specdir /usr/src/RPM/BUILD/rpminstall-tests-1.1.3/SPECS' --define '_srcrpmdir /usr/src/RPM/BUILD/rpminstall-tests-1.1.3/SRPMS/reqGreaterEpoch' --define '_rpmdir /usr/src/RPM/BUILD/rpminstall-tests-1.1.3/RPMS/reqGreaterEpoch' --define 'disttag %nil' -bb SPECS/reqGreaterEpoch.spec
Executing(%install): /bin/sh -e /usr/src/tmp/sh.gBIe5aAr/rpm-tmp.35258
+ umask 022
+ /bin/mkdir -p /usr/src/tmp/sh.gBIe5aAr/BUILD
+ cd /usr/src/tmp/sh.gBIe5aAr/BUILD
+ /bin/chmod -Rf u+rwX -- /usr/src/tmp/sh.gBIe5aAr/reqGreaterEpoch-buildroot
+ :
+ /bin/rm -rf -- /usr/src/tmp/sh.gBIe5aAr/reqGreaterEpoch-buildroot
++ dirname /etc/rpminstall-tests/reqGreaterEpoch
+ mkdir -p /usr/src/tmp/sh.gBIe5aAr/reqGreaterEpoch-buildroot/etc/rpminstall-tests
+ echo /usr/src/tmp/sh.gBIe5aAr/reqGreaterEpoch-buildroot
+ /usr/lib/rpm/brp-alt
Cleaning files in /usr/src/tmp/sh.gBIe5aAr/reqGreaterEpoch-buildroot (auto)
Verifying and fixing files in /usr/src/tmp/sh.gBIe5aAr/reqGreaterEpoch-buildroot (binconfig,pkgconfig,libtool,desktop)
Compressing files in /usr/src/tmp/sh.gBIe5aAr/reqGreaterEpoch-buildroot (auto)
Verifying ELF objects in /usr/src/tmp/sh.gBIe5aAr/reqGreaterEpoch-buildroot (arch=normal,fhs=normal,lfs=relaxed,lint=relaxed,rpath=normal,stack=normal,textrel=normal,unresolved=normal)
Hardlinking identical .pyc and .pyo files
Processing files: reqGreaterEpoch-1-alt1
Requires: dummy > 0:1-alt1
Wrote: /usr/src/RPM/BUILD/rpminstall-tests-1.1.3/RPMS/reqGreaterEpoch/noarch/reqGreaterEpoch-1-alt1.noarch.rpm
rpm --dbpath '/usr/src/tmp/sh.ouaNq0ha' --justdb -i RPMS/dummy2/noarch/dummy-1-alt2.noarch.rpm RPMS/reqGreaterEpoch/noarch/reqGreaterEpoch-1-alt1.noarch.rpm
make[1]: Leaving directory `/usr/src/RPM/BUILD/rpminstall-tests-1.1.3'
TESTED
TESTING noninstallable_dummy0_with_reqGreaterEpoch
make[1]: Entering directory `/usr/src/RPM/BUILD/rpminstall-tests-1.1.3'
! rpm --dbpath '/usr/src/tmp/sh.N1bUUdY1' --justdb -i RPMS/dummy0/noarch/dummy-1-alt0.noarch.rpm RPMS/reqGreaterEpoch/noarch/reqGreaterEpoch-1-alt1.noarch.rpm
error: failed dependencies:
	dummy > 0:1-alt1 is needed by reqGreaterEpoch-1-alt1
make[1]: Leaving directory `/usr/src/RPM/BUILD/rpminstall-tests-1.1.3'
TESTED
TESTING installable_dummyV2_with_reqGreaterEpoch
make[1]: Entering directory `/usr/src/RPM/BUILD/rpminstall-tests-1.1.3'
rpm --dbpath '/usr/src/tmp/sh.r5sidyqk' --justdb -i RPMS/dummyV2/noarch/dummy-2-alt1.noarch.rpm RPMS/reqGreaterEpoch/noarch/reqGreaterEpoch-1-alt1.noarch.rpm
make[1]: Leaving directory `/usr/src/RPM/BUILD/rpminstall-tests-1.1.3'
TESTED
TESTING noninstallable_dummyV0_with_reqGreaterEpoch
make[1]: Entering directory `/usr/src/RPM/BUILD/rpminstall-tests-1.1.3'
! rpm --dbpath '/usr/src/tmp/sh.kHGnAJFS' --justdb -i RPMS/dummyV0/noarch/dummy-0-alt1.noarch.rpm RPMS/reqGreaterEpoch/noarch/reqGreaterEpoch-1-alt1.noarch.rpm
error: failed dependencies:
	dummy > 0:1-alt1 is needed by reqGreaterEpoch-1-alt1
make[1]: Leaving directory `/usr/src/RPM/BUILD/rpminstall-tests-1.1.3'
TESTED
TESTING installable_dummyEpoch1_with_reqGreaterEpoch
make[1]: Entering directory `/usr/src/RPM/BUILD/rpminstall-tests-1.1.3'
mkdir -p SPECS
cat >SPECS/dummyEpoch1.spec <<-'EOF'
Name: dummy
Epoch: 1
Version: 1
Release: alt1
License: dummy license
Group: Other
Summary: dummy summy

BuildArch: noarch


AutoReq: no
AutoProv: no


%description
dummy desc

%install

mkdir -p %buildroot`dirname /etc/rpminstall-tests/%name`
# Fill it with some unique value; each time new.
# (We rely on the fact that %%buildroot comes from mktemp.)
echo %buildroot >%buildroot/etc/rpminstall-tests/%name


%files
/etc/rpminstall-tests/%name
EOF
. /usr/lib/rpm/tmpdir.sh
rpmbuild --define "_tmppath $tmpdir" --define "_builddir $tmpdir/BUILD" --define "_topdir /usr/src/RPM/BUILD/rpminstall-tests-1.1.3" --define '_sourcedir /usr/src/RPM/BUILD/rpminstall-tests-1.1.3' --define '_specdir /usr/src/RPM/BUILD/rpminstall-tests-1.1.3/SPECS' --define '_srcrpmdir /usr/src/RPM/BUILD/rpminstall-tests-1.1.3/SRPMS/dummyEpoch1' --define '_rpmdir /usr/src/RPM/BUILD/rpminstall-tests-1.1.3/RPMS/dummyEpoch1' --define 'disttag %nil' -bb SPECS/dummyEpoch1.spec
Executing(%install): /bin/sh -e /usr/src/tmp/sh.pgCUnuAy/rpm-tmp.9047
+ umask 022
+ /bin/mkdir -p /usr/src/tmp/sh.pgCUnuAy/BUILD
+ cd /usr/src/tmp/sh.pgCUnuAy/BUILD
+ /bin/chmod -Rf u+rwX -- /usr/src/tmp/sh.pgCUnuAy/dummy-buildroot
+ :
+ /bin/rm -rf -- /usr/src/tmp/sh.pgCUnuAy/dummy-buildroot
++ dirname /etc/rpminstall-tests/dummy
+ mkdir -p /usr/src/tmp/sh.pgCUnuAy/dummy-buildroot/etc/rpminstall-tests
+ echo /usr/src/tmp/sh.pgCUnuAy/dummy-buildroot
+ /usr/lib/rpm/brp-alt
Cleaning files in /usr/src/tmp/sh.pgCUnuAy/dummy-buildroot (auto)
Verifying and fixing files in /usr/src/tmp/sh.pgCUnuAy/dummy-buildroot (binconfig,pkgconfig,libtool,desktop)
Compressing files in /usr/src/tmp/sh.pgCUnuAy/dummy-buildroot (auto)
Verifying ELF objects in /usr/src/tmp/sh.pgCUnuAy/dummy-buildroot (arch=normal,fhs=normal,lfs=relaxed,lint=relaxed,rpath=normal,stack=normal,textrel=normal,unresolved=normal)
Hardlinking identical .pyc and .pyo files
Processing files: dummy-1-alt1
Wrote: /usr/src/RPM/BUILD/rpminstall-tests-1.1.3/RPMS/dummyEpoch1/noarch/dummy-1-alt1.noarch.rpm
rpm --dbpath '/usr/src/tmp/sh.1Qsn4dny' --justdb -i RPMS/dummyEpoch1/noarch/dummy-1-alt1.noarch.rpm RPMS/reqGreaterEpoch/noarch/reqGreaterEpoch-1-alt1.noarch.rpm
make[1]: Leaving directory `/usr/src/RPM/BUILD/rpminstall-tests-1.1.3'
TESTED
TESTING noninstallable_dummy_with_reqGreaterEpoch
make[1]: Entering directory `/usr/src/RPM/BUILD/rpminstall-tests-1.1.3'
! rpm --dbpath '/usr/src/tmp/sh.c6EMm0v6' --justdb -i RPMS/dummy/noarch/dummy-1-alt1.noarch.rpm RPMS/reqGreaterEpoch/noarch/reqGreaterEpoch-1-alt1.noarch.rpm
error: failed dependencies:
	dummy > 0:1-alt1 is needed by reqGreaterEpoch-1-alt1
make[1]: Leaving directory `/usr/src/RPM/BUILD/rpminstall-tests-1.1.3'
TESTED
TESTING noninstallable_virtDummy_with_reqGreaterEpoch
make[1]: Entering directory `/usr/src/RPM/BUILD/rpminstall-tests-1.1.3'
! rpm --dbpath '/usr/src/tmp/sh.YwnGTrsH' --justdb -i RPMS/virtDummy/noarch/virtDummy-1-alt1.noarch.rpm RPMS/reqGreaterEpoch/noarch/reqGreaterEpoch-1-alt1.noarch.rpm
error: failed dependencies:
	dummy > 0:1-alt1 is needed by reqGreaterEpoch-1-alt1
make[1]: Leaving directory `/usr/src/RPM/BUILD/rpminstall-tests-1.1.3'
TESTED
TESTING noninstallable_virtDummyDisttag_with_reqGreaterEpoch
make[1]: Entering directory `/usr/src/RPM/BUILD/rpminstall-tests-1.1.3'
! rpm --dbpath '/usr/src/tmp/sh.YGwjGCJm' --justdb -i RPMS/virtDummyDisttag/noarch/virtDummyDisttag-1-alt1.noarch.rpm RPMS/reqGreaterEpoch/noarch/reqGreaterEpoch-1-alt1.noarch.rpm
error: failed dependencies:
	dummy > 0:1-alt1 is needed by reqGreaterEpoch-1-alt1
make[1]: Leaving directory `/usr/src/RPM/BUILD/rpminstall-tests-1.1.3'
TESTED

########################################
# 2) Requires с указанием только V
########################################

$ < /tasks/archive/done/_$(( 243303 / 1024 ))/243303/build/300/x86_64/log sed -re '/^TESTING / i TESTED' |sed -nre '\|^\+ \./makeme\.sh.*1$|,\|^\+ \./makeme\.sh.*clean$| { /TESTING .*_with_reqGreaterOnlyV$/,/TESTED/ p; }'       
TESTING noninstallable_dummy2_with_reqGreaterOnlyV
make[1]: Entering directory `/usr/src/RPM/BUILD/rpminstall-tests-1.1.3'
mkdir -p SPECS
cat >SPECS/reqGreaterOnlyV.spec <<-'EOF'
Name: reqGreaterOnlyV

Version: 1
Release: alt1
License: dummy license
Group: Other
Summary: dummy summy

BuildArch: noarch


AutoReq: no
AutoProv: no
Requires: dummy > 1

%description
dummy desc

%install

mkdir -p %buildroot`dirname /etc/rpminstall-tests/%name`
# Fill it with some unique value; each time new.
# (We rely on the fact that %%buildroot comes from mktemp.)
echo %buildroot >%buildroot/etc/rpminstall-tests/%name


%files
/etc/rpminstall-tests/%name
EOF
. /usr/lib/rpm/tmpdir.sh
rpmbuild --define "_tmppath $tmpdir" --define "_builddir $tmpdir/BUILD" --define "_topdir /usr/src/RPM/BUILD/rpminstall-tests-1.1.3" --define '_sourcedir /usr/src/RPM/BUILD/rpminstall-tests-1.1.3' --define '_specdir /usr/src/RPM/BUILD/rpminstall-tests-1.1.3/SPECS' --define '_srcrpmdir /usr/src/RPM/BUILD/rpminstall-tests-1.1.3/SRPMS/reqGreaterOnlyV' --define '_rpmdir /usr/src/RPM/BUILD/rpminstall-tests-1.1.3/RPMS/reqGreaterOnlyV' --define 'disttag %nil' -bb SPECS/reqGreaterOnlyV.spec
Executing(%install): /bin/sh -e /usr/src/tmp/sh.pE8kdoKF/rpm-tmp.70745
+ umask 022
+ /bin/mkdir -p /usr/src/tmp/sh.pE8kdoKF/BUILD
+ cd /usr/src/tmp/sh.pE8kdoKF/BUILD
+ /bin/chmod -Rf u+rwX -- /usr/src/tmp/sh.pE8kdoKF/reqGreaterOnlyV-buildroot
+ :
+ /bin/rm -rf -- /usr/src/tmp/sh.pE8kdoKF/reqGreaterOnlyV-buildroot
++ dirname /etc/rpminstall-tests/reqGreaterOnlyV
+ mkdir -p /usr/src/tmp/sh.pE8kdoKF/reqGreaterOnlyV-buildroot/etc/rpminstall-tests
+ echo /usr/src/tmp/sh.pE8kdoKF/reqGreaterOnlyV-buildroot
+ /usr/lib/rpm/brp-alt
Cleaning files in /usr/src/tmp/sh.pE8kdoKF/reqGreaterOnlyV-buildroot (auto)
Verifying and fixing files in /usr/src/tmp/sh.pE8kdoKF/reqGreaterOnlyV-buildroot (binconfig,pkgconfig,libtool,desktop)
Compressing files in /usr/src/tmp/sh.pE8kdoKF/reqGreaterOnlyV-buildroot (auto)
Verifying ELF objects in /usr/src/tmp/sh.pE8kdoKF/reqGreaterOnlyV-buildroot (arch=normal,fhs=normal,lfs=relaxed,lint=relaxed,rpath=normal,stack=normal,textrel=normal,unresolved=normal)
Hardlinking identical .pyc and .pyo files
Processing files: reqGreaterOnlyV-1-alt1
Requires: dummy > 1
Wrote: /usr/src/RPM/BUILD/rpminstall-tests-1.1.3/RPMS/reqGreaterOnlyV/noarch/reqGreaterOnlyV-1-alt1.noarch.rpm
! rpm --dbpath '/usr/src/tmp/sh.OPaCWGCn' --justdb -i RPMS/dummy2/noarch/dummy-1-alt2.noarch.rpm RPMS/reqGreaterOnlyV/noarch/reqGreaterOnlyV-1-alt1.noarch.rpm
error: failed dependencies:
	dummy > 1 is needed by reqGreaterOnlyV-1-alt1
make[1]: Leaving directory `/usr/src/RPM/BUILD/rpminstall-tests-1.1.3'
TESTED
TESTING noninstallable_dummy0_with_reqGreaterOnlyV
make[1]: Entering directory `/usr/src/RPM/BUILD/rpminstall-tests-1.1.3'
! rpm --dbpath '/usr/src/tmp/sh.DRci80Iv' --justdb -i RPMS/dummy0/noarch/dummy-1-alt0.noarch.rpm RPMS/reqGreaterOnlyV/noarch/reqGreaterOnlyV-1-alt1.noarch.rpm
error: failed dependencies:
	dummy > 1 is needed by reqGreaterOnlyV-1-alt1
make[1]: Leaving directory `/usr/src/RPM/BUILD/rpminstall-tests-1.1.3'
TESTED
TESTING installable_dummyV2_with_reqGreaterOnlyV
make[1]: Entering directory `/usr/src/RPM/BUILD/rpminstall-tests-1.1.3'
rpm --dbpath '/usr/src/tmp/sh.owseR0e3' --justdb -i RPMS/dummyV2/noarch/dummy-2-alt1.noarch.rpm RPMS/reqGreaterOnlyV/noarch/reqGreaterOnlyV-1-alt1.noarch.rpm
make[1]: Leaving directory `/usr/src/RPM/BUILD/rpminstall-tests-1.1.3'
TESTED
TESTING noninstallable_dummyV0_with_reqGreaterOnlyV
make[1]: Entering directory `/usr/src/RPM/BUILD/rpminstall-tests-1.1.3'
! rpm --dbpath '/usr/src/tmp/sh.VVb4c7OR' --justdb -i RPMS/dummyV0/noarch/dummy-0-alt1.noarch.rpm RPMS/reqGreaterOnlyV/noarch/reqGreaterOnlyV-1-alt1.noarch.rpm
error: failed dependencies:
	dummy > 1 is needed by reqGreaterOnlyV-1-alt1
make[1]: Leaving directory `/usr/src/RPM/BUILD/rpminstall-tests-1.1.3'
TESTED
TESTING noninstallable_dummyEpoch1_with_reqGreaterOnlyV
make[1]: Entering directory `/usr/src/RPM/BUILD/rpminstall-tests-1.1.3'
! rpm --dbpath '/usr/src/tmp/sh.67EUKrtG' --justdb -i RPMS/dummyEpoch1/noarch/dummy-1-alt1.noarch.rpm RPMS/reqGreaterOnlyV/noarch/reqGreaterOnlyV-1-alt1.noarch.rpm
error: failed dependencies:
	dummy > 1 is needed by reqGreaterOnlyV-1-alt1
make[1]: Leaving directory `/usr/src/RPM/BUILD/rpminstall-tests-1.1.3'
TESTED
TESTING noninstallable_dummy_with_reqGreaterOnlyV
make[1]: Entering directory `/usr/src/RPM/BUILD/rpminstall-tests-1.1.3'
! rpm --dbpath '/usr/src/tmp/sh.olD7rmea' --justdb -i RPMS/dummy/noarch/dummy-1-alt1.noarch.rpm RPMS/reqGreaterOnlyV/noarch/reqGreaterOnlyV-1-alt1.noarch.rpm
error: failed dependencies:
	dummy > 1 is needed by reqGreaterOnlyV-1-alt1
make[1]: Leaving directory `/usr/src/RPM/BUILD/rpminstall-tests-1.1.3'
TESTED
TESTING noninstallable_virtDummy_with_reqGreaterOnlyV
make[1]: Entering directory `/usr/src/RPM/BUILD/rpminstall-tests-1.1.3'
! rpm --dbpath '/usr/src/tmp/sh.t7JvR3HY' --justdb -i RPMS/virtDummy/noarch/virtDummy-1-alt1.noarch.rpm RPMS/reqGreaterOnlyV/noarch/reqGreaterOnlyV-1-alt1.noarch.rpm
error: failed dependencies:
	dummy > 1 is needed by reqGreaterOnlyV-1-alt1
make[1]: Leaving directory `/usr/src/RPM/BUILD/rpminstall-tests-1.1.3'
TESTED
TESTING noninstallable_virtDummyDisttag_with_reqGreaterOnlyV
make[1]: Entering directory `/usr/src/RPM/BUILD/rpminstall-tests-1.1.3'
! rpm --dbpath '/usr/src/tmp/sh.amewnMAy' --justdb -i RPMS/virtDummyDisttag/noarch/virtDummyDisttag-1-alt1.noarch.rpm RPMS/reqGreaterOnlyV/noarch/reqGreaterOnlyV-1-alt1.noarch.rpm
error: failed dependencies:
	dummy > 1 is needed by reqGreaterOnlyV-1-alt1
make[1]: Leaving directory `/usr/src/RPM/BUILD/rpminstall-tests-1.1.3'
TESTED

########################################
# 3) Requires с указанием V-R
########################################

$ < /tasks/archive/done/_$(( 243303 / 1024 ))/243303/build/300/x86_64/log sed -re '/^TESTING / i TESTED' |sed -nre '\|^\+ \./makeme\.sh.*1$|,\|^\+ \./makeme\.sh.*clean$| { /TESTING .*_with_reqGreater$/,/TESTED/ p; }'       
TESTING installable_dummy2_with_reqGreater
make[1]: Entering directory `/usr/src/RPM/BUILD/rpminstall-tests-1.1.3'
mkdir -p SPECS
cat >SPECS/reqGreater.spec <<-'EOF'
Name: reqGreater

Version: 1
Release: alt1
License: dummy license
Group: Other
Summary: dummy summy

BuildArch: noarch


AutoReq: no
AutoProv: no
Requires: dummy > 1-alt1

%description
dummy desc

%install

mkdir -p %buildroot`dirname /etc/rpminstall-tests/%name`
# Fill it with some unique value; each time new.
# (We rely on the fact that %%buildroot comes from mktemp.)
echo %buildroot >%buildroot/etc/rpminstall-tests/%name


%files
/etc/rpminstall-tests/%name
EOF
. /usr/lib/rpm/tmpdir.sh
rpmbuild --define "_tmppath $tmpdir" --define "_builddir $tmpdir/BUILD" --define "_topdir /usr/src/RPM/BUILD/rpminstall-tests-1.1.3" --define '_sourcedir /usr/src/RPM/BUILD/rpminstall-tests-1.1.3' --define '_specdir /usr/src/RPM/BUILD/rpminstall-tests-1.1.3/SPECS' --define '_srcrpmdir /usr/src/RPM/BUILD/rpminstall-tests-1.1.3/SRPMS/reqGreater' --define '_rpmdir /usr/src/RPM/BUILD/rpminstall-tests-1.1.3/RPMS/reqGreater' --define 'disttag %nil' -bb SPECS/reqGreater.spec
Executing(%install): /bin/sh -e /usr/src/tmp/sh.xR3c8fHj/rpm-tmp.67188
+ umask 022
+ /bin/mkdir -p /usr/src/tmp/sh.xR3c8fHj/BUILD
+ cd /usr/src/tmp/sh.xR3c8fHj/BUILD
+ /bin/chmod -Rf u+rwX -- /usr/src/tmp/sh.xR3c8fHj/reqGreater-buildroot
+ :
+ /bin/rm -rf -- /usr/src/tmp/sh.xR3c8fHj/reqGreater-buildroot
++ dirname /etc/rpminstall-tests/reqGreater
+ mkdir -p /usr/src/tmp/sh.xR3c8fHj/reqGreater-buildroot/etc/rpminstall-tests
+ echo /usr/src/tmp/sh.xR3c8fHj/reqGreater-buildroot
+ /usr/lib/rpm/brp-alt
Cleaning files in /usr/src/tmp/sh.xR3c8fHj/reqGreater-buildroot (auto)
Verifying and fixing files in /usr/src/tmp/sh.xR3c8fHj/reqGreater-buildroot (binconfig,pkgconfig,libtool,desktop)
Compressing files in /usr/src/tmp/sh.xR3c8fHj/reqGreater-buildroot (auto)
Verifying ELF objects in /usr/src/tmp/sh.xR3c8fHj/reqGreater-buildroot (arch=normal,fhs=normal,lfs=relaxed,lint=relaxed,rpath=normal,stack=normal,textrel=normal,unresolved=normal)
Hardlinking identical .pyc and .pyo files
Processing files: reqGreater-1-alt1
Requires: dummy > 1-alt1
Wrote: /usr/src/RPM/BUILD/rpminstall-tests-1.1.3/RPMS/reqGreater/noarch/reqGreater-1-alt1.noarch.rpm
rpm --dbpath '/usr/src/tmp/sh.AntTXmD6' --justdb -i RPMS/dummy2/noarch/dummy-1-alt2.noarch.rpm RPMS/reqGreater/noarch/reqGreater-1-alt1.noarch.rpm
make[1]: Leaving directory `/usr/src/RPM/BUILD/rpminstall-tests-1.1.3'
TESTED
TESTING noninstallable_dummy0_with_reqGreater
make[1]: Entering directory `/usr/src/RPM/BUILD/rpminstall-tests-1.1.3'
! rpm --dbpath '/usr/src/tmp/sh.EwXNrctu' --justdb -i RPMS/dummy0/noarch/dummy-1-alt0.noarch.rpm RPMS/reqGreater/noarch/reqGreater-1-alt1.noarch.rpm
error: failed dependencies:
	dummy > 1-alt1 is needed by reqGreater-1-alt1
make[1]: Leaving directory `/usr/src/RPM/BUILD/rpminstall-tests-1.1.3'
TESTED
TESTING installable_dummyV2_with_reqGreater
make[1]: Entering directory `/usr/src/RPM/BUILD/rpminstall-tests-1.1.3'
rpm --dbpath '/usr/src/tmp/sh.uAKOkNfs' --justdb -i RPMS/dummyV2/noarch/dummy-2-alt1.noarch.rpm RPMS/reqGreater/noarch/reqGreater-1-alt1.noarch.rpm
make[1]: Leaving directory `/usr/src/RPM/BUILD/rpminstall-tests-1.1.3'
TESTED
TESTING noninstallable_dummyV0_with_reqGreater
make[1]: Entering directory `/usr/src/RPM/BUILD/rpminstall-tests-1.1.3'
! rpm --dbpath '/usr/src/tmp/sh.OqK7gqKv' --justdb -i RPMS/dummyV0/noarch/dummy-0-alt1.noarch.rpm RPMS/reqGreater/noarch/reqGreater-1-alt1.noarch.rpm
error: failed dependencies:
	dummy > 1-alt1 is needed by reqGreater-1-alt1
make[1]: Leaving directory `/usr/src/RPM/BUILD/rpminstall-tests-1.1.3'
TESTED
TESTING installable_dummyEpoch1_with_reqGreater
make[1]: Entering directory `/usr/src/RPM/BUILD/rpminstall-tests-1.1.3'
rpm --dbpath '/usr/src/tmp/sh.3lu4iYq5' --justdb -i RPMS/dummyEpoch1/noarch/dummy-1-alt1.noarch.rpm RPMS/reqGreater/noarch/reqGreater-1-alt1.noarch.rpm
error: failed dependencies:
	dummy > 1-alt1 is needed by reqGreater-1-alt1
make[1]: *** [installable_dummyEpoch1_with_reqGreater] Error 2
make[1]: Leaving directory `/usr/src/RPM/BUILD/rpminstall-tests-1.1.3'
TESTED
TESTING noninstallable_dummy_with_reqGreater
make[1]: Entering directory `/usr/src/RPM/BUILD/rpminstall-tests-1.1.3'
! rpm --dbpath '/usr/src/tmp/sh.rOayxL1N' --justdb -i RPMS/dummy/noarch/dummy-1-alt1.noarch.rpm RPMS/reqGreater/noarch/reqGreater-1-alt1.noarch.rpm
error: failed dependencies:
	dummy > 1-alt1 is needed by reqGreater-1-alt1
make[1]: Leaving directory `/usr/src/RPM/BUILD/rpminstall-tests-1.1.3'
TESTED
TESTING noninstallable_virtDummy_with_reqGreater
make[1]: Entering directory `/usr/src/RPM/BUILD/rpminstall-tests-1.1.3'
! rpm --dbpath '/usr/src/tmp/sh.osC0xce8' --justdb -i RPMS/virtDummy/noarch/virtDummy-1-alt1.noarch.rpm RPMS/reqGreater/noarch/reqGreater-1-alt1.noarch.rpm
error: failed dependencies:
	dummy > 1-alt1 is needed by reqGreater-1-alt1
make[1]: Leaving directory `/usr/src/RPM/BUILD/rpminstall-tests-1.1.3'
TESTED
TESTING noninstallable_virtDummyDisttag_with_reqGreater
make[1]: Entering directory `/usr/src/RPM/BUILD/rpminstall-tests-1.1.3'
! rpm --dbpath '/usr/src/tmp/sh.C2IxVCf2' --justdb -i RPMS/virtDummyDisttag/noarch/virtDummyDisttag-1-alt1.noarch.rpm RPMS/reqGreater/noarch/reqGreater-1-alt1.noarch.rpm
error: failed dependencies:
	dummy > 1-alt1 is needed by reqGreater-1-alt1
make[1]: Leaving directory `/usr/src/RPM/BUILD/rpminstall-tests-1.1.3'
TESTED


У меня в 3) тест installable_dummyEpoch1_with_reqGreater ожидается
успешным из-за вот этих спорных вопросов про значение собственно
релиза в зависимости без эпохи, которые я озвучил в своём предыдущем
письме.

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

Для полноты картины ещё не хватает примера с бОльшим релизом и бОльшей
эпохой. По моей системе я бы его назвал как-то вроде
installable_dummy2Epoch1_with_reqGreater.

Re: [devel] Сборка новой версии после использования epoch

[Mikhail Novosyolov]

10.02.2020 05:36, Ivan Zakharyaschev пишет:
> У меня в 3) тест installable_dummyEpoch1_with_reqGreater ожидается
> успешным из-за вот этих спорных вопросов про значение собственно
> релиза в зависимости без эпохи, которые я озвучил в своём предыдущем
> письме.
>
> Реальное поведение, что сравниваются и версия, и релиз, но не эпоха в
> таком случае, поэтому зависимость оказывается не удовлетворена.

А в чем смысл такого переделывания основ сравнения версий в rpm? или в apt? Тогда вообще не понятно, как эпоха работает в ALT.

После такого http://git.altlinux.org/gears/p/pamtester.git?p=pamtester.git;a=commitdiff;h=a1f7608dcd53c63e327320246f441c05552ad0a5 установленный пакет обновится?

> Хочется ли, чтобы G, H, I могли удволетворить этот Requires?
>
> Я так понял Ваши слова, что не хочется. (Правильно?) Т.е. не хочется, 
> чтобы более старая версия (upstream-а) могла удволетворить эту 
> завиисимость, пусть и с повышенной эпохой в пакете?
Я ожидаю, что эпоха приоритетнее версии, т.е. 1:1-alt1 > 2-alt1 и что, если установлен пакет "foo = 1:1-alt1", то он удовлетворит зависимость "Requires: foo >= 2-alt1".

Re: [devel] Сборка новой версии после использования epoch

[Ivan Zakharyaschev]

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


On Wed, 12 Feb 2020, Mikhail Novosyolov wrote:

> > Хочется ли, чтобы G, H, I могли удволетворить этот Requires?
> >
> > Я так понял Ваши слова, что не хочется. (Правильно?) Т.е. не хочется, 
> > чтобы более старая версия (upstream-а) могла удволетворить эту 
> > завиисимость, пусть и с повышенной эпохой в пакете?
> Я ожидаю, что эпоха приоритетнее версии, т.е. 1:1-alt1 > 2-alt1 и что, если установлен пакет "foo = 1:1-alt1", то он удовлетворит зависимость "Requires: foo >= 2-alt1".

Нет, у нас не так.

Сравниваются только те компоненты, которые указаны в зависимости.

Например (в дополнение к Вашему), если Вы укажете Requires: foo >= 2

то неважно, какая эпоха будет у пакета, главное, чтобы версия была такая 
(2 или больше).

Обоснование этому я, например, знаю такое: чтобы после отката релиза (с 
повышением эпохи) требование версии всё равно работало правильно.

Т.е. если вы откатите foo на 1:1-alt1, то он не удволетворит
Requires: foo >= 2

Потому что во 2ой версии могли быть нужные фичи, которых ещё нет в 1ой.

Вам мой пример с указанием только версии не кажется более приемлемым?

Ещё я высказывал сомнение, что при указании релиза в Requires тоже стоит 
игнорировать эпоху. Потому что это всё-таки отсылка к конкретному релизу. 
И хотел, чтобы участника сообщества высказали совё мнение о таком 
потенциальном изменении. Жаль, что ни у кого не было мнения по этому 
вопросу, потому что он меня уже некоторое время волнует -- с тех пор, как 
я стал писать тесты на поведение rpm и должен был указать какое-то 
поведение как ожидаемое и правильное.

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

-- 
Best regards,
Ivan

Re: [devel] Сборка новой версии после использования epoch

[Mikhail Novosyolov]

12.02.2020 02:23, Ivan Zakharyaschev пишет:
> On Wed, 12 Feb 2020, Mikhail Novosyolov wrote:
>
>>> Хочется ли, чтобы G, H, I могли удволетворить этот Requires?
>>>
>>> Я так понял Ваши слова, что не хочется. (Правильно?) Т.е. не хочется, 
>>> чтобы более старая версия (upstream-а) могла удволетворить эту 
>>> завиисимость, пусть и с повышенной эпохой в пакете?
>> Я ожидаю, что эпоха приоритетнее версии, т.е. 1:1-alt1 > 2-alt1 и что, если установлен пакет "foo = 1:1-alt1", то он удовлетворит зависимость "Requires: foo >= 2-alt1".
> Нет, у нас не так.
>
> Сравниваются только те компоненты, которые указаны в зависимости.
>
> Например (в дополнение к Вашему), если Вы укажете Requires: foo >= 2
>
> то неважно, какая эпоха будет у пакета, главное, чтобы версия была такая 
> (2 или больше).
Спасибо за пояснение. Это бы еще где-то документировать...
> Обоснование этому я, например, знаю такое: чтобы после отката релиза (с 
> повышением эпохи) требование версии всё равно работало правильно.
>
> Т.е. если вы откатите foo на 1:1-alt1, то он не удволетворит
> Requires: foo >= 2
Для отката Release достаточно поднять Release на один, Вы, скорее всего, имели в виду откат Version.
> Потому что во 2ой версии могли быть нужные фичи, которых ещё нет в 1ой.
>
> Вам мой пример с указанием только версии не кажется более приемлемым?
>
> Ещё я высказывал сомнение, что при указании релиза в Requires тоже стоит 
> игнорировать эпоху. Потому что это всё-таки отсылка к конкретному релизу. 
> И хотел, чтобы участника сообщества высказали совё мнение о таком 
> потенциальном изменении.
возможно, если Release != ( alt1 | 1 | 0 | alt0 ) и т.д. Но тогда получится еще более непредсказуемо для недостаточно прошаренного мейнтейнера. Как-то привычно писать V-R, а не просто V, я бы релиз машинально на всякий случай и для читаемости написал.
> Жаль, что ни у кого не было мнения по этому 
> вопросу, потому что он меня уже некоторое время волнует -- с тех пор, как 
> я стал писать тесты на поведение rpm и должен был указать какое-то 
> поведение как ожидаемое и правильное.
>
> Мне показалось, что требовать сравнения релиза, но не сравнения эпохи 
> в общем-то бессмысленно с т.ч. зрения мейнтейнера, пишущего спекфайл.

Re: [devel] Сборка новой версии после использования epoch

[Ivan Zakharyaschev]

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

On Wed, 12 Feb 2020, Mikhail Novosyolov wrote:

> 12.02.2020 02:23, Ivan Zakharyaschev пишет:
> > On Wed, 12 Feb 2020, Mikhail Novosyolov wrote:
> >
> >>> Хочется ли, чтобы G, H, I могли удволетворить этот Requires?
> >>>
> >>> Я так понял Ваши слова, что не хочется. (Правильно?) Т.е. не хочется, 
> >>> чтобы более старая версия (upstream-а) могла удволетворить эту 
> >>> завиисимость, пусть и с повышенной эпохой в пакете?
> >> Я ожидаю, что эпоха приоритетнее версии, т.е. 1:1-alt1 > 2-alt1 и что, если установлен пакет "foo = 1:1-alt1", то он удовлетворит зависимость "Requires: foo >= 2-alt1".
> > Нет, у нас не так.
> >
> > Сравниваются только те компоненты, которые указаны в зависимости.
> >
> > Например (в дополнение к Вашему), если Вы укажете Requires: foo >= 2
> >
> > то неважно, какая эпоха будет у пакета, главное, чтобы версия была такая 
> > (2 или больше).
> Спасибо за пояснение. Это бы еще где-то документировать...

Предлагайте изменения, вносите изменения, если есть желание.

> > Обоснование этому я, например, знаю такое: чтобы после отката релиза (с 
> > повышением эпохи) требование версии всё равно работало правильно.
> >
> > Т.е. если вы откатите foo на 1:1-alt1, то он не удволетворит
> > Requires: foo >= 2
> Для отката Release достаточно поднять Release на один, Вы, скорее всего, имели в виду откат Version.

Да, Вы правы.

Если точнее, я имел в виду откат на ранее выпущенный пакет. При этом 
возможно и понижении Version.

> > Потому что во 2ой версии могли быть нужные фичи, которых ещё нет в 1ой.
> >
> > Вам мой пример с указанием только версии не кажется более приемлемым?
> >
> > Ещё я высказывал сомнение, что при указании релиза в Requires тоже стоит 
> > игнорировать эпоху. Потому что это всё-таки отсылка к конкретному релизу. 
> > И хотел, чтобы участника сообщества высказали совё мнение о таком 
> > потенциальном изменении.

> возможно, если Release != ( alt1 | 1 | 0 | alt0 ) и т.д. Но тогда 
> получится еще более непредсказуемо для недостаточно прошаренного 
> мейнтейнера. Как-то привычно писать V-R, а не просто V, я бы релиз 
> машинально на всякий случай и для читаемости написал.

Спасибо за мнение. Действительно, нынешнее правило хорошо хотя бы своей 
простотой (те компоненты, которые указаны в Requires, те и сравниваются).

Можно warning в rpm-build добавить, если кто-то пишет что-то вроде 
Requires: foo >= 2-alt1, но не указаывает эпоху. ("Осмысленно указывать 
только V или E:V-R")

> > Жаль, что ни у кого не было мнения по этому 
> > вопросу, потому что он меня уже некоторое время волнует -- с тех пор, как 
> > я стал писать тесты на поведение rpm и должен был указать какое-то 
> > поведение как ожидаемое и правильное.
> >
> > Мне показалось, что требовать сравнения релиза, но не сравнения эпохи 
> > в общем-то бессмысленно с т.ч. зрения мейнтейнера, пишущего спекфайл.
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] Сборка новой версии после использования epoch

[Mikhail Novosyolov]

12.02.2020 13:58, Ivan Zakharyaschev пишет:
>> Спасибо за пояснение. Это бы еще где-то документировать...
> Предлагайте изменения, вносите изменения, если есть желание.

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

То есть я бы не стал ждать, что сообщество напишет подобную документацию.

Re: [devel] Сборка новой версии после использования epoch

[Mikhail Novosyolov]

12.02.2020 22:05, Mikhail Novosyolov пишет:
> 12.02.2020 13:58, Ivan Zakharyaschev пишет:
>>> Спасибо за пояснение. Это бы еще где-то документировать...
>> Предлагайте изменения, вносите изменения, если есть желание.
> Даже если бы было большое желание таким заняться, чтобы это описать, пришлось бы изучить код альтовского форка rpm и apt. При чем очень тщательно. А это почти невозможно, нюансы пропустятся.
>
> То есть я бы не стал ждать, что сообщество напишет подобную документацию.
>
Впрочем, Вы уже сами в предыдущих письмах документировали это поведение, но большинство людей не попадут на эти тексты, поскольку, чтобы туда попасть, потребуется весьма специфических поисковый запрос.

Re: [devel] Сборка новой версии после использования epoch

[Ivan Zakharyaschev]

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

On Wed, 12 Feb 2020, Mikhail Novosyolov wrote:

> 12.02.2020 22:05, Mikhail Novosyolov пишет:
> > 12.02.2020 13:58, Ivan Zakharyaschev пишет:
> >>> Спасибо за пояснение. Это бы еще где-то документировать...
> >> Предлагайте изменения, вносите изменения, если есть желание.
> > Даже если бы было большое желание таким заняться, чтобы это описать, 
> > пришлось бы изучить код альтовского форка rpm и apt. При чем очень 
> > тщательно. А это почти невозможно, нюансы пропустятся.
> >
> > То есть я бы не стал ждать, что сообщество напишет подобную документацию.
> >
> Впрочем, Вы уже сами в предыдущих письмах документировали это поведение, 
> но большинство людей не попадут на эти тексты, поскольку, чтобы туда 
> попасть, потребуется весьма специфических поисковый запрос.

Предлагайте место, куда скопировать (где бы Вы нашли с большой 
вероятностью), или сами скопируйте, если есть желание.

Ещё это было описано в changelog (то, что касается отношения 
обновляемости между пакетами):

* Вт июн 11 2019 Ivan Zakharyaschev <imz@altlinux.org> 4.13.0.1-alt9
- lib: introduced rpmEVRDTCompare() (useful for APT).
- Changes in what is considered "newer" by rpm -U  pertaining to disttag
  comparison. (On the whole, to determine which package is "newer", first,
  the EVRs are compared, then the branch prefixes of the disttags if the
  disttags are present, and then the buildtimes.) The comparison of the disttags:
  + Before the comparison of disttags, an optional initial padding
    (which is terminated by :) is skipped. (This will be useful for
    generating >,<-deps compatible with disttag-unaware rpm & apt.)
  + If a disttag contains no + separator (old format), the branch prefix is
    assumed to be empty (and hence "older" than any other branch prefix).
  + If the branch prefix of a disttag is equal to %_priority_distbranch
    (and it is not empty), then it is "newer" than any other ones.
  + The branch prefixes of disttags are ordered by rpmvercmp() rather than
    lexicographically. (For example, the numeric parts of "p8" or "p10" are
    compared as numbers. However, the first letter in "p7" or "c8.1" is more
    significant.)
- Give a default value to %_priority_distbranch based on the disttag
  when this package is built (the prefix before +),
  i.e., the current repo branch by default.
  (Useful for getting the rpm tool with good behavior in branches (like p9)
  forked off Sisyphus after disttags were introduced.)

Также исходный код этой функции довольно понятен и даёт точное описание 
алгоритма обновляемости, которое я описывал словами вчера:

http://git.altlinux.org/gears/r/rpm.git?p=rpm.git;a=blob;f=lib/rpmvercmp.c;h=93bb4ff644e92460b331d57bd06d5a368d9b1eb6;hb=31123348f4c6b33563ffc986d0ba4db57c7477f5#l203

/* Decide which package is "newer" (for upgrade).
 */
int rpmEVRDTCompare(const struct rpmEVRDT * const fst,
                    const struct rpmEVRDT * const snd)
{
    int rc = 0; /* same "new" (an upgrade in neither direction is possible) */

    rc = rpm_cmp_uint(fst->has_epoch ? fst->epoch : 0,
                      snd->has_epoch ? snd->epoch : 0);

    if (rc) return rc;

    if (!fst->version && snd->version)
        rc = -1;
    if (fst->version && !snd->version)
        rc = 1;
    if (fst->version && snd->version)
        rc = rpmvercmp(fst->version,
                       snd->version);

    if (rc) return rc;

    if (!fst->release && snd->release)
        rc = -1;
    if (fst->release && !snd->release)
        rc = 1;
    if (fst->release && snd->release)
        rc = rpmvercmp(fst->release,
                       snd->release);

    if (rc) return rc;

    /* NB: if one of disttags is absent, we don't decide based on the disttags;
       rather we fallback to the decision based on the buildtimes.
    */
    if (fst->disttag && snd->disttag)
        rc = rpm_cmp_disttag(fst->disttag,
                             snd->disttag);

    if (rc) return rc;

    if (upgrade_honor_buildtime()) {
        /* Currently an absent buildtime is treated as the least one.
           Another possibility could be to skip buildtime comparison then.
           However, the current treatment is good for the work of hsh --with-stuff
           in case when buildtime is absent in the non-local repo indexes.
        */
        if (!fst->has_buildtime && snd->has_buildtime)
            rc = -1;
        if (fst->has_buildtime && !snd->has_buildtime)
            rc = 1;
        if (fst->has_buildtime && snd->has_buildtime)
            rc = rpm_cmp_uint(fst->buildtime,
                              snd->buildtime);
    }

    return rc;
}


-- 
Best regards,
Ivan

Re: [devel] Сборка новой версии после использования epoch

[Ivan Zakharyaschev]

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

On Wed, 12 Feb 2020, Mikhail Novosyolov wrote:

> 10.02.2020 05:36, Ivan Zakharyaschev пишет:
> > У меня в 3) тест installable_dummyEpoch1_with_reqGreater ожидается
> > успешным из-за вот этих спорных вопросов про значение собственно
> > релиза в зависимости без эпохи, которые я озвучил в своём предыдущем
> > письме.
> >
> > Реальное поведение, что сравниваются и версия, и релиз, но не эпоха в
> > таком случае, поэтому зависимость оказывается не удовлетворена.
> 
> А в чем смысл такого переделывания основ сравнения версий в rpm? или в apt?

В rpm в первую очередь. (В apt должно быть также.)

Кажется, в своих изменениях в apt я старался не реализовать алгоритмы 
заново, а использовать функции из rpm.

> Тогда вообще не понятно, как эпоха работает в ALT.
> 
> После такого http://git.altlinux.org/gears/p/pamtester.git?p=pamtester.git;a=commitdiff;h=a1f7608dcd53c63e327320246f441c05552ad0a5 установленный пакет обновится?

Да, обновляемость у нас линейный порядок, в котором все компоненты 
сравниваются. (E:V-R:D@T)

Он не совпадает с удволетворением зависимостей.

Re: [devel] Сборка новой версии после использования epoch

[Ivan Zakharyaschev]

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

On Wed, 12 Feb 2020, Ivan Zakharyaschev wrote:

> On Wed, 12 Feb 2020, Mikhail Novosyolov wrote:

> > Тогда вообще не понятно, как эпоха работает в ALT.
> > 
> > После такого http://git.altlinux.org/gears/p/pamtester.git?p=pamtester.git;a=commitdiff;h=a1f7608dcd53c63e327320246f441c05552ad0a5 установленный пакет обновится?
>
> Да,

(Да, обновится.)

> обновляемость у нас линейный порядок, в котором все компоненты 
> сравниваются. (E:V-R:D@T)
> 
> Он не совпадает с удволетворением зависимостей.

Дополнение:

Для порядка обновляемости, если в пакете была опущена эпоха, она считается 
равной 0.

Могу ещё дополнить подробностями:

Если отсутствует disttag (D) хотя бы у одного пакета (в паре 
сравниваемых), то он вообще не играет роли при сравнении.

Можно считать, что время сборки (T) есть у пакетов всегда и оно различно, 
поэтому порядок получается строго линейным: в последнюю очередь 
сравнивается оно (если сравнение предыдущих компонентов не привело к тому, 
что один пакет считается предпочтительным, т.е. другими словами, по 
предыдущим компонентам они оказались одинаково предпочтительными).

Наверное, если и время сборки совпало, пакеты не различимы при 
обновлении...

-- 
Best regards,
Ivan

Re: [devel] Сборка новой версии после использования epoch

[Dmitry V. Levin]

On Wed, Jan 29, 2020 at 12:35:22PM +0300, Dmitry V. Levin wrote:
> On Wed, Jan 29, 2020 at 11:24:50AM +0300, Alexey V. Vissarionov wrote:
> > On 2020-01-29 02:15:37 +0300, Pavel Vainerman wrote:
> >  >>> Если я хочу собрать новую версию библиотеки 6.4.5 могу ли я
> >  >>> удалить epoch или это уже навсегда?
> >  > Я пока не определился. Новая версия требует c++17 (как раз мне
> >  > понадобилось в проекте). А я так понимаю ещё многие библиотеки
> >  > ещё не готовы к с++17. С другой стороны от libpqxx сейчас зависит
> >  > только один мой пакет )
> > 
> > Тогда возможен такой вариант: удалить оба пакета и собрать их уже
> > без epoch. Да, поломается обновление, но для двух пакетов это не
> > критично.
> 
> Скоро в сборочнице будет проверка, которая это жульничество запретит.

Теперь в сборочнице эта проверка есть.
Жульнические пакеты будут удалены.

Пример диагностики можно посмотреть тут:
https://lists.altlinux.org/pipermail/sisyphus-incominger/2020-March/563268.html


-- 
ldv

Re: [devel] Сборка новой версии после использования epoch

[Pavel Vainerman]

>>> Тогда возможен такой вариант: удалить оба пакета и собрать их уже
>>> без epoch. Да, поломается обновление, но для двух пакетов это не
>>> критично.
>>
>> Скоро в сборочнице будет проверка, которая это жульничество запретит.
> 
> Теперь в сборочнице эта проверка есть.
> Жульнические пакеты будут удалены.
> 
> Пример диагностики можно посмотреть тут:
> https://lists.altlinux.org/pipermail/sisyphus-incominger/2020-March/563268.html

  Понял )

Я думал если никто от пакета не зависит, то это можно провернуть. Эх.


-- 
Pavel Vainerman