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

[Alexey Tourbin <alexey.tourbin@gmail.com>]

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-функции). Если интересует, могу подробнее
> написать о положении дел в этой области.