[devel] [#166699] rpm-4.13-rc1 + rpmbuild-4.0.4-alt + apt-rpm

[devel] [#166699] rpm-4.13-rc1 + rpmbuild-4.0.4-alt + apt-rpm

[Gleb Fotengauer-Malinovskiy]

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

Всем привет!

Завершена первая стадия переноса наших фич [1] на современную версию rpm.
Идея первой стадии состоит в том, чтобы можно было использовать для
установки новый rpm, а для сборки привычный нам altrpm.

Понятно, что кучу всяких программ придётся перетаскивать на новый API
librpm.  На данный момент силами legion@ был перенесён apt.  Всё остальное
не было исследовано и будет не работать или работать странно. :)

Всё, что сделано, находится в таске:
http://git.altlinux.org/tasks/166699/

[1] https://www.altlinux.org/Rpm-4.13

-- 
glebfm

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [devel] [#166699] rpm-4.13-rc1 + rpmbuild-4.0.4-alt + apt-rpm

[Sergey Afonin]

On Tuesday 19 July 2016, Gleb Fotengauer-Malinovskiy wrote:

> Завершена первая стадия переноса наших фич [1] на современную версию rpm.

Спасибо за начало сдвигания горы. :-) Но вопрос, а почему rpm-4.13,
а не rpm5 ? Или сложностей больше ?

> Понятно, что кучу всяких программ придётся перетаскивать на новый API
> librpm.  На данный момент силами legion@ был перенесён apt.  Всё остальное
> не было исследовано и будет не работать или работать странно. :)

Глядя на 

	ACLs of affected packages:
appliance-rescue-static	mithraen @everybody
rpmdevtools	real viy @python
rpmlint	evg @everybody

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

-- 
С уважением, Сергей Афонин.

Re: [devel] [#166699] rpm-4.13-rc1 + rpmbuild-4.0.4-alt + apt-rpm

[Aleksey Novodvorsky]

20 июля 2016 г., 11:54 пользователь akv@altlinux.org
<gbophuk_alt@mail.ru> написал:
>
>
>
> Среда, 20 июля 2016, 11:22 +03:00 от Sergey Afonin <asy@altlinux.ru>:
>
> On Tuesday 19 July 2016, Gleb Fotengauer-Malinovskiy wrote:
>
>> Завершена первая стадия переноса наших фич [1] на современную версию rpm.
>
> Спасибо за начало сдвигания горы. :-) Но вопрос, а почему rpm-4.13,
> а не rpm5 ? Или сложностей больше ?
>
> Я далёк от этих тем про rpm-ы.
> Но беглое гугление создало впечатление что это два независимых проекта =)))

Да.

> Нашёл обсуждение на http://www.linux.org.ru/forum/talks/7389256 - там даже
> про ALTLinux есть немного.
> Видимо, на 4.13 сейча легче перейти.

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

Rgrds, Алексей

Re: [devel] [#166699] rpm-4.13-rc1 + rpmbuild-4.0.4-alt + apt-rpm

[Sergey Afonin]

On Wednesday 20 July 2016, Aleksey Novodvorsky wrote:

> Не знаю, легче ли, но, на мой взгляд, рациональнее.
> rpm5 мало кто  использует и неизвестно будет ли.
> Нам  разумнее обеспечить совместимость с RH, сохранив свои фичи и
> предложив их апстриму.

Мысль понятна, но, с другой стороны, на rpm5 ROSA сидит, а она тут ближе.

Кстати, попалось сравнение у них: http://wiki.rosalab.ru/ru/index.php/RPM5
Вообще, действительно, не очень понятно, что лучше.

-- 
С уважением, Сергей Афонин.

Re: [devel] [#166699] rpm-4.13-rc1 + rpmbuild-4.0.4-alt + apt-rpm

[Aleksey Novodvorsky]

20 июля 2016 г., 17:20 пользователь Sergey Afonin <asy@altlinux.ru> написал:
> On Wednesday 20 July 2016, Aleksey Novodvorsky wrote:
>
>> Не знаю, легче ли, но, на мой взгляд, рациональнее.
>> rpm5 мало кто  использует и неизвестно будет ли.
>> Нам  разумнее обеспечить совместимость с RH, сохранив свои фичи и
>> предложив их апстриму.
>
> Мысль понятна, но, с другой стороны, на rpm5 ROSA сидит, а она тут ближе.

ROSA выпускает несколько дистрибутивов, в большинстве из них используется rpm-4

>
> Кстати, попалось сравнение у них: http://wiki.rosalab.ru/ru/index.php/RPM5

2012 года

Rgrds, Алексей

Re: [devel] [#166699] rpm-4.13-rc1 + rpmbuild-4.0.4-alt + apt-rpm

[Vitaly Lipatov]

Aleksey Novodvorsky писал 20.7.16 17:33:
...
>> Мысль понятна, но, с другой стороны, на rpm5 ROSA сидит, а она тут 
>> ближе.
> 
> ROSA выпускает несколько дистрибутивов, в большинстве из них 
> используется rpm-4
> 
>> 
>> Кстати, попалось сравнение у них: 
>> http://wiki.rosalab.ru/ru/index.php/RPM5
> 
> 2012 года
Насколько мне помнится, на rpm5 перешла Mandriva незадолго до 
превращения в Росу. И они пожалели об этом, но решили не менять ничего 
(в силу каких-то проблем).
То есть использование rpm5 в дистрибутивах Роса нельзя назвать их 
осознанным и аргументированным выбором.

А совместимость с апстримом rpm, то есть с RHEL/Fedora — действительно 
важная задача.

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

Re: [devel] [#166699] rpm-4.13-rc1 + rpmbuild-4.0.4-alt + apt-rpm

[Sergey Afonin]

On Wednesday 20 July 2016, akv@altlinux.org wrote:

> Но беглое гугление создало впечатление что это два
> независимых проекта =)))  

Я знаю. Как раз причина выбора интересна.

-- 
С уважением, Сергей Афонин.

Re: [devel] [#166699] rpm-4.13-rc1 + rpmbuild-4.0.4-alt + apt-rpm

[Gleb Fotengauer-Malinovskiy]

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

On Wed, Jul 20, 2016 at 12:22:43PM +0400, Sergey Afonin wrote:
> On Tuesday 19 July 2016, Gleb Fotengauer-Malinovskiy wrote:
> 
> > Завершена первая стадия переноса наших фич [1] на современную версию rpm.
> 
> Спасибо за начало сдвигания горы. :-) Но вопрос, а почему rpm-4.13,
> а не rpm5 ? Или сложностей больше ?

И это и тот факт, что rpm-4.13 выглядит более поддерживаемым.  А rpm5 из
известных мне пользуются только PLD и Роса.  К тому же, RH и SUSE как
апстрим и возможность для совместимости выглядит интереснее.

Хотя начал я с того, что портировал самые базовые вещи на оба и получил
нерабочий rpm5 и рабочий rpm4, что, конечно, оказалось более существенным
при выборе. :)

> > Понятно, что кучу всяких программ придётся перетаскивать на новый API
> > librpm.  На данный момент силами legion@ был перенесён apt.  Всё остальное
> > не было исследовано и будет не работать или работать странно. :)
> 
> Глядя на 
> 
> 	ACLs of affected packages:
> appliance-rescue-static	mithraen @everybody
> rpmdevtools	real viy @python
> rpmlint	evg @everybody
> 
> в задании, не так уж и много, на первый взгляд... Или речь про что-то,
> что сборочница не ловит ?

Тут только зависимость на rpm-static является проблемой, остальные это
ошибка нынешней запаковки rpm, которую я исправлю: там python-module-rpm
не провайдит rpm-python.

А проблемы с зависимостями на librpm сейчас вообще не отражены, потому что
старый librpm пока на месте, он нужен rpm-build-4.0.4.

-- 
glebfm

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [devel] [#166699] rpm-4.13-rc1 + rpmbuild-4.0.4-alt + apt-rpm

[Alexey Tourbin]

2016-07-19 17:58 GMT+03:00 Gleb Fotengauer-Malinovskiy <glebfm@altlinux.org>:
> Всем привет!
>
> Завершена первая стадия переноса наших фич [1] на современную версию rpm.
> Идея первой стадии состоит в том, чтобы можно было использовать для
> установки новый rpm, а для сборки привычный нам altrpm.

На мой взгляд, для этого изменения, с учетом его сложности, не имеется
достаточных оснований - по крайней мере, если усматривать эти
основания в области каких-то реальных улучшений при сборке или при
установке пакетов, а не в области получения денег за первую, вторую и
все последующие стадии работ. Ниже упоминается совместимость с RH, но
не разъясняется, что это такое. Поскольку rpm является инструментом
нижнего уровня (управления пакетами), то никакой особенной
совместимости для пользователя и не нужно: ему, как правило, вообще
противопоказано запускать rpm вручную. Попытка сделать из rpm
инструмент более высокого уровня ведет ко всяким нелепостям: помню,
Vitus Wagner первым делом попытался импортировать свой PGP-ключ в базу
/var/lib/rpmdb, и отсутствие совместимости с RH - ключ не
импортируется - его, так сказать, неприятно удивило.

Вообще, в области улучшения rpm многие ходячие идеи на поверку
оказываются нелепостями. Помню еще читал тезисы доклада Дениса
Силакова. Он пишет: "пользователи могут заметить прирост
производительности при установке пакетов на многоядерных машинах, где
RPM5 способен выполнять параллельно несколько действий на разных ядрах
процессора". На самом деле самым узким местом при серийной установке
пакетов является скорость распаковки lzma payload, которая в несколько
раз меньше скорости записи на жесткий диск; распараллелить распаковку
lzma никак нельзя. Силаков дальше пишет: "В настоящее время
распараллеливание используется при обработке групп пакетов (для
проверки их подписей, контрольных сумм и тому подобного). Возможность
использования параллелизма на более низком уровне (например, для
разархивирования содержимого пакета — одного из наиболее затратных по
времени действий) исследуется, однако внедрение подобных механизмов
сопряжено с существенными техническими трудностями и требует
тщательного тестирования." Но ведь проверка подписей выполняется на
более высоком уровне - на уровне репозитория (средствами apt). Если
репозиторий (как функция от входящих в него пакетов) подписан, то на
уровне rpm подписи самих пакетов уже проверять не надо. А
распараллеливание файловых операций при установке - да, невозможно и
требует тщательного тестирования.

Контрольный вопрос: а что там в rpm-4.13 с Epoch? В старом rpm когда
есть Provides c Epoch, то Requires без Epoch (вида Requires: N =
V[-R]) трактуется как Requires: {MATCH_ANY_EPOCH_OR_NO_EPOCH}:V[-R].
Таким образом, если мы хотим привязаться к апстримной версии, то нам
не нужно знать эпоху пакета. В новом rpm вроде бы потом сделали что во
всех зависимостях отсутствующий Epoch принудительно трактуется как
Epoch=0. Так что логика привязки к апстримной версии работать больше
не будет.

Я еще временами обдумывал, как можно улучшить set-версии, а именно,
как можно к символам добавить поддержку прототипов/сигнатур (наподобие
C++ mangling, но для C-функции). Если интересует, могу подробнее
написать о положении дел в этой области.

Re: [devel] [#166699] rpm-4.13-rc1 + rpmbuild-4.0.4-alt + apt-rpm

[Alexey Tourbin]

2016-07-21 4:09 GMT+03:00 Alexey Tourbin <alexey.tourbin@gmail.com>:
> 2016-07-19 17:58 GMT+03:00 Gleb Fotengauer-Malinovskiy <glebfm@altlinux.org>:
>> Всем привет!
>>
>> Завершена первая стадия переноса наших фич [1] на современную версию rpm.
>> Идея первой стадии состоит в том, чтобы можно было использовать для
>> установки новый rpm, а для сборки привычный нам altrpm.
>
> На мой взгляд, для этого изменения, с учетом его сложности, не имеется
> достаточных оснований - по крайней мере, если усматривать эти
> основания в области каких-то реальных улучшений при сборке или при
> установке пакетов, а не в области получения денег за первую, вторую и
> все последующие стадии работ. Ниже упоминается совместимость с RH, но
> не разъясняется, что это такое. Поскольку rpm является инструментом
> нижнего уровня (управления пакетами), то никакой особенной
> совместимости для пользователя и не нужно: ему, как правило, вообще
> противопоказано запускать rpm вручную. Попытка сделать из rpm
> инструмент более высокого уровня ведет ко всяким нелепостям: помню,
> Vitus Wagner первым делом попытался импортировать свой PGP-ключ в базу
> /var/lib/rpmdb, и отсутствие совместимости с RH - ключ не
> импортируется - его, так сказать, неприятно удивило.
>
> Вообще, в области улучшения rpm многие ходячие идеи на поверку
> оказываются нелепостями. Помню еще читал тезисы доклада Дениса
> Силакова. Он пишет: "пользователи могут заметить прирост
> производительности при установке пакетов на многоядерных машинах, где
> RPM5 способен выполнять параллельно несколько действий на разных ядрах
> процессора". На самом деле самым узким местом при серийной установке
> пакетов является скорость распаковки lzma payload, которая в несколько
> раз меньше скорости записи на жесткий диск; распараллелить распаковку
> lzma никак нельзя. Силаков дальше пишет: "В настоящее время
> распараллеливание используется при обработке групп пакетов (для
> проверки их подписей, контрольных сумм и тому подобного). Возможность
> использования параллелизма на более низком уровне (например, для
> разархивирования содержимого пакета — одного из наиболее затратных по
> времени действий) исследуется, однако внедрение подобных механизмов
> сопряжено с существенными техническими трудностями и требует
> тщательного тестирования." Но ведь проверка подписей выполняется на
> более высоком уровне - на уровне репозитория (средствами apt). Если
> репозиторий (как функция от входящих в него пакетов) подписан, то на
> уровне rpm подписи самих пакетов уже проверять не надо. А
> распараллеливание файловых операций при установке - да, невозможно и
> требует тщательного тестирования.
>
> Контрольный вопрос: а что там в rpm-4.13 с Epoch? В старом rpm когда
> есть Provides c Epoch, то Requires без Epoch (вида Requires: N =
> V[-R]) трактуется как Requires: {MATCH_ANY_EPOCH_OR_NO_EPOCH}:V[-R].
> Таким образом, если мы хотим привязаться к апстримной версии, то нам
> не нужно знать эпоху пакета. В новом rpm вроде бы потом сделали что во
> всех зависимостях отсутствующий Epoch принудительно трактуется как
> Epoch=0. Так что логика привязки к апстримной версии работать больше
> не будет.

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

> Я еще временами обдумывал, как можно улучшить set-версии, а именно,
> как можно к символам добавить поддержку прототипов/сигнатур (наподобие
> C++ mangling, но для C-функции). Если интересует, могу подробнее
> написать о положении дел в этой области.

Re: [devel] [#166699] rpm-4.13-rc1 + rpmbuild-4.0.4-alt + apt-rpm

[Hihin Ruslan]

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

Здравствуйте Alexey Tourbin
  В сообщении от 7 августа 2016 Alexey Tourbin написал(a):
> Отсутствие ответов на контрольные вопросы демонстрирует
> некомпетенцию. На остальное, конечно, можно отвечать по
> желанию.

Читаю ваше письмо, и в силу своих татарских корней не могу 
удержаться сказать вам спасибо. 
Иногда вопросы, поставленные вовремя имеют большее значение, чем 
ответы на них. 
Просьба не обижаться на отсутствие ответов на них и продолжить 
вашу мысль про новаый rpm.

Т.е. говоря русским языком - раньше provides работало на любую 
версию пакета, а теперь она привязана к нулевой версии, и 
придётся в новом rpm что-то делать?

А какие ваши предложения по этому вопросу? 

-- 
  А ещё говорят так  (fortune): 
 
Disclose classified information only when a NEED TO KNOW exists. 
________________________________________________________________________
С уважением Хихин Руслан 

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [devel] [#166699] rpm-4.13-rc1 + rpmbuild-4.0.4-alt + apt-rpm

[Andrew Clark]

7 августа 2016 г., 10:18 пользователь Alexey Tourbin
<alexey.tourbin@gmail.com> написал:

> Отсутствие ответов на контрольные вопросы демонстрирует некомпетенцию.
> На остальное, конечно, можно отвечать по желанию.

Может быть не стоит разводить трали-вали?

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

После такого предположения - можно дальше не читать. Все понятно становится.


-- 
Talk is cheap, show me the code (c) Linus Torvalds

Re: [devel] [#166699] rpm-4.13-rc1 + rpmbuild-4.0.4-alt + apt-rpm

[Alexey Tourbin]

2016-08-07 10:30 GMT+03:00 Andrew Clark <andrewclarkii@gmail.com>:
>> Отсутствие ответов на контрольные вопросы демонстрирует некомпетенцию.
>> На остальное, конечно, можно отвечать по желанию.
>
> Может быть не стоит разводить трали-вали?

Отсутствует ответ на вопрос, что происходит с зависимостью вида
Requires: binutils >= 2.26

По старой семантике, она может быть удовлетворена только апстримной
версией >= 2.26. По новой семантике, эта зависимость удовлетворяется
наличием в пакете Epoch: 1; апстримная версия может быть любой.

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

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

Re: [devel] [#166699] rpm-4.13-rc1 + rpmbuild-4.0.4-alt + apt-rpm

[Hihin Ruslan]

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

Здравствуйте Alexey Tourbin
  В сообщении от 7 августа 2016 Alexey Tourbin написал(a):
> По старой семантике, она может быть удовлетворена только
> апстримной версией >= 2.26. По новой семантике, эта
> зависимость удовлетворяется наличием в пакете Epoch: 1;
> апстримная версия может быть любой.

Т.е не понял - в каком пакете должна быть Epoch: 1 - в пакете, 
или в binutils.
А если binutils имеет эпоху 2? 


-- 
  А ещё говорят так  (fortune): 
 
There is no such thing as a problem without a gift for you in its 
hands. 
________________________________________________________________________
С уважением Хихин Руслан 

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [devel] [#166699] rpm-4.13-rc1 + rpmbuild-4.0.4-alt + apt-rpm

[Alexey Tourbin]

2016-08-07 10:46 GMT+03:00 Hihin Ruslan <ruslandh@gmail.com>:
>   В сообщении от 7 августа 2016 Alexey Tourbin написал(a):
>> По старой семантике, она может быть удовлетворена только
>> апстримной версией >= 2.26. По новой семантике, эта
>> зависимость удовлетворяется наличием в пакете Epoch: 1;
>> апстримная версия может быть любой.
>
> Т.е не понял - в каком пакете должна быть Epoch: 1 - в пакете,
> или в binutils.

Сейчас в binutils есть Epoch.

$ rpm -q --qf '[%{EPOCH}:%{VERSION}\n]' binutils
1:2.26.0

Это значит, что ЛЮБАЯ зависимость на binutils по новой семантике будет
удовлетворена. Например, Requires: binutils >=666.

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

Re: [devel] [#166699] rpm-4.13-rc1 + rpmbuild-4.0.4-alt + apt-rpm

[Hihin Ruslan]

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

Здравствуйте Alexey Tourbin
  В сообщении от 7 августа 2016 Alexey Tourbin написал(a):
> Сейчас в binutils есть Epoch.
>
> $ rpm -q --qf '[%{EPOCH}:%{VERSION}\n]' binutils
> 1:2.26.0
>
> Это значит, что ЛЮБАЯ зависимость на binutils по новой
> семантике будет удовлетворена. Например, Requires: binutils
> >=666.
Да, проблемка.

> Но вы зачем у меня спрашиваете? Вы спрашиваете у ваших этих
> там духовных лидеров. Может они когда-нибудь соблаговолят вам
> ответить; если сами поймут, что там к чему.
Да вроде не в Иране. Можно и напрямую общаться. 

PS по теории управления (что впрочем соответствует и классической 
физике) горизонтальные связи всегда устойчивее, чем вертикальные 
(для физики - рановесное состояние  передмета в положении 
вертикали требует дополнительных сил, в отличии от 
горизонтального положения).

-- 
  А ещё говорят так  (fortune): 
 
The little town that time forgot, Where all the women are strong, 
The men are good-looking, And the children above-average. -- 
Prairie Home Companion 
________________________________________________________________________
С уважением Хихин Руслан 

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [devel] [#166699] rpm-4.13-rc1 + rpmbuild-4.0.4-alt + apt-rpm

[Hihin Ruslan]

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

Здравствуйте Alexey Tourbin
  В сообщении от 7 августа 2016 Alexey Tourbin написал(a):
> Сейчас в binutils есть Epoch.
>
> $ rpm -q --qf '[%{EPOCH}:%{VERSION}\n]' binutils
> 1:2.26.0

Кстати, пытаяст собрать новый TDE, столкнулся с тем, что в спеках 
прямо указывает эпоха при provides, requires и conflicts - это 
оно?

-- 
  А ещё говорят так  (fortune): 
 
Osborn's Law: Variables won't; constants aren't. 
________________________________________________________________________
С уважением Хихин Руслан 

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [devel] [#166699] rpm-4.13-rc1 + rpmbuild-4.0.4-alt + apt-rpm

[Hihin Ruslan]

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

Здравствуйте Aleksey Novodvorsky
  В сообщении от 7 августа 2016 Aleksey Novodvorsky написал(a):
>  Кстати, пытаяст собрать новый TDE, столкнулся с тем, что в
> спеках
>
> > прямо указывает эпоха при provides, requires и conflicts -
> > это оно?
>
> Новый rpm пока не в Сизифе, так что если Вы его не тестируете
> специально, то это точно не оно.

Нет - причём тут Сизиф - я о спеках Федоры/Сюзи:

Например в tdelibs.spec:

# Trinity dependencies
BuildRequires:  libtqt4-devel = %{tde_epoch}:4.2.0
....
Requires:               trinity-arts >= %{tde_epoch}:1.5.10

А в tqtinterface-14.0.0.spec:

Provides:       libtqt4 = %{?epoch:
%{epoch}:}%{version}-%{release}

Как я понимаю, там уже "тот" rpm, который "готовит" Глеб.

Просто, или нужен патч на rpm, устранющий эту "фичу", или 
готовить механизм перехода на неё.

А Глеб пусть отдыхает, ведь это не только его косается.

-- 
  А ещё говорят так  (fortune): 
 
QOTD: "A child of 5 could understand this! Fetch me a child of 
5." 
________________________________________________________________________
С уважением Хихин Руслан 

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [devel] %{?epoch:%epoch:}

[Dmitry V. Levin]

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

On Sun, Aug 07, 2016 at 05:11:36PM +0300, Hihin Ruslan wrote:
>   В сообщении от 7 августа 2016 Aleksey Novodvorsky написал(a):
> >  Кстати, пытаяст собрать новый TDE, столкнулся с тем, что в
> > спеках
> >
> > > прямо указывает эпоха при provides, requires и conflicts -
> > > это оно?
> >
> > Новый rpm пока не в Сизифе, так что если Вы его не тестируете
> > специально, то это точно не оно.
> 
> Нет - причём тут Сизиф - я о спеках Федоры/Сюзи:
> 
> Например в tdelibs.spec:
> 
> # Trinity dependencies
> BuildRequires:  libtqt4-devel = %{tde_epoch}:4.2.0
> ....
> Requires:               trinity-arts >= %{tde_epoch}:1.5.10
> 
> А в tqtinterface-14.0.0.spec:
> 
> Provides:       libtqt4 = %{?epoch:
> %{epoch}:}%{version}-%{release}

Существует такой стиль спекописания.  У нас для этого есть макрос EVR:
$ rpm --showrc |grep EVR
-14: EVR	%{?epoch:%epoch:}%{version}-%{release}


-- 
ldv

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

Re: [devel] %{?epoch:%epoch:}

[Hihin Ruslan]

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

Здравствуйте Dmitry V. Levin
  В сообщении от 7 августа 2016 Dmitry V. Levin написал(a):
> > Provides:       libtqt4 = %{?epoch:
> > %{epoch}:}%{version}-%{release}
>
> Существует такой стиль спекописания.  У нас для этого есть
> макрос EVR: $ rpm --showrc |grep EVR
> -14: EVR        %{?epoch:%epoch:}%{version}-%{release}

Правильно-ли я понимаю, что при использовании такого стиля не 
возможна проблема, описанная Алексеем Турбиным?


> "Это значит, что ЛЮБАЯ зависимость на binutils по новой
> семантике будет удовлетворена. Например, 
> Requires: binutils >=666." 

-- 
  А ещё говорят так  (fortune): 
 
"Flattery is all right -- if you don't inhale." -- Adlai 
Stevenson 
________________________________________________________________________
С уважением Хихин Руслан 

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [devel] %{?epoch:%epoch:}

[Dmitry V. Levin]

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

On Sun, Aug 07, 2016 at 07:38:03PM +0300, Hihin Ruslan wrote:
> Здравствуйте Dmitry V. Levin
>   В сообщении от 7 августа 2016 Dmitry V. Levin написал(a):
> > > Provides:       libtqt4 = %{?epoch:
> > > %{epoch}:}%{version}-%{release}
> >
> > Существует такой стиль спекописания.  У нас для этого есть
> > макрос EVR: $ rpm --showrc |grep EVR
> > -14: EVR        %{?epoch:%epoch:}%{version}-%{release}
> 
> Правильно-ли я понимаю, что при использовании такого стиля не 
> возможна проблема, описанная Алексеем Турбиным?
> 
> > "Это значит, что ЛЮБАЯ зависимость на binutils по новой
> > семантике будет удовлетворена. Например, 
> > Requires: binutils >=666." 

Это очень слабо связанные вещи.


-- 
ldv

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

Re: [devel] [#166699] rpm-4.13-rc1 + rpmbuild-4.0.4-alt + apt-rpm

[Alexey Tourbin]

2016-08-07 10:46 GMT+03:00 Hihin Ruslan <ruslandh@gmail.com>:
> Здравствуйте Alexey Tourbin
>   В сообщении от 7 августа 2016 Alexey Tourbin написал(a):
>> По старой семантике, она может быть удовлетворена только
>> апстримной версией >= 2.26. По новой семантике, эта
>> зависимость удовлетворяется наличием в пакете Epoch: 1;
>> апстримная версия может быть любой.
>
> Т.е не понял - в каком пакете должна быть Epoch: 1 - в пакете,
> или в binutils.
> А если binutils имеет эпоху 2?

Руслан с татарскими корнями, как Державин, которого я очень люблю.
Какая вам разница? Epoch быть нигде не "должна". Но речь идет о
сравнении версий в принципе. Откройте какой-нибудь учебник по
дискретной математике, там написано, что сравнение версий - это
рефлексивное антисимметричное транзитивное отношение. А отношение
означает, кто кого больше. С новым rpm понять кто кого больше не
представляется возможным. Отношение не поддается исчислению, как
квадратный корень из 100.

Re: [devel] [#166699] rpm-4.13-rc1 + rpmbuild-4.0.4-alt + apt-rpm

[Hihin Ruslan]

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

Здравствуйте Alexey Tourbin
  В сообщении от 7 августа 2016 Alexey Tourbin написал(a):
> С новым rpm понять кто кого больше не
> представляется возможным.
А если ввести меру?


-- 
  А ещё говорят так  (fortune): 
 
For most men life is a search for the proper manila envelope in 
which to get themselves filed. -- Clifton Fadiman 
________________________________________________________________________
С уважением Хихин Руслан 

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [devel] [#166699] rpm-4.13-rc1 + rpmbuild-4.0.4-alt + apt-rpm

[@ 2016-08-07 8:06 UTC (permalink / raw)]

Re: [devel] [#166699] rpm-4.13-rc1 + rpmbuild-4.0.4-alt + apt-rpm

[@ 2016-08-07 8:34 UTC (permalink / raw)]

Re: [devel] [#166699] rpm-4.13-rc1 + rpmbuild-4.0.4-alt + apt-rpm

[@ 2016-08-07 11:08 UTC (permalink / raw)]

Re: [devel] [#166699] rpm-4.13-rc1 + rpmbuild-4.0.4-alt + apt-rpm

[@ 2016-08-07 18:59 UTC (permalink / raw)]

Re: [devel] [#166699] rpm-4.13-rc1 + rpmbuild-4.0.4-alt + apt-rpm

[@ 2016-08-08 6:13 UTC (permalink / raw)]

Re: [devel] [#166699] rpm-4.13-rc1 + rpmbuild-4.0.4-alt + apt-rpm

[@ 2016-08-08 8:26 UTC (permalink / raw)]

Re: [devel] [#166699] rpm-4.13-rc1 + rpmbuild-4.0.4-alt + apt-rpm

[@ 2016-08-08 8:41 UTC (permalink / raw)]

Re: [devel] [#166699] rpm-4.13-rc1 + rpmbuild-4.0.4-alt + apt-rpm

[@ 2016-08-08 9:11 UTC (permalink / raw)]

Re: [devel] [#166699] rpm-4.13-rc1 + rpmbuild-4.0.4-alt + apt-rpm

[@ 2016-08-09 13:22 UTC (permalink / raw)]

Re: [devel] [#166699] rpm-4.13-rc1 + rpmbuild-4.0.4-alt + apt-rpm

[@ 2016-08-09 14:42 UTC (permalink / raw)]

Re: [devel] [#166699] rpm-4.13-rc1 + rpmbuild-4.0.4-alt + apt-rpm

[@ 2016-08-08 9:17 UTC (permalink / raw)]

Re: [devel] [#166699] rpm-4.13-rc1 + rpmbuild-4.0.4-alt + apt-rpm

[@ 2016-08-08 9:25 UTC (permalink / raw)]

Re: [devel] [#166699] rpm-4.13-rc1 + rpmbuild-4.0.4-alt + apt-rpm

[@ 2016-08-08 9:42 UTC (permalink / raw)]

Re: [devel] [#166699] rpm-4.13-rc1 + rpmbuild-4.0.4-alt + apt-rpm

[@ 2016-08-08 9:44 UTC (permalink / raw)]