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