Re: [devel] печальные последствия перехода на rpm-4.13

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

2017-01-25 20:42 GMT+03:00 Gleb Fotengauer-Malinovskiy <glebfm@altlinux.org>:
> Hi,
>
> On Wed, Jan 25, 2017 at 07:48:12AM +0300, Alexey Tourbin wrote:
>> Уважаемые мужчины!
>>
>> Вследствие перехода на rpm-4.13 в вашем национальном дистрибутиве
>> наблюдается многократное замедление работы.
>>
>> Вот как сканировал пакеты старый rpm:
> [...]
>> Предварительный осмотр показывает, что rpm теперь вычисляет какие-то
>> хитрые SHA1-суммы.
>
> Никакой хитрости, оно сравнивает SHA1HEADER с реальностью.  Мне не кажется
> это совсем плохой идеей, а для чтения тысяч файлов всегда можно сделать
> %__vsflags = %__vsflags|_RPMVSF_NODIGESTS, например 0xf0f00.

Есть какой-то принцип, в соответствии с которым имеют смысл только
иерархически скоординированные сравнения с реальностью; а любые вообще
проверки дороже assert() тогда объявляются wasteful. Например, если
контрольная сумма проверяется на протоколе более высокого уровня, то
нет уже никакого смысла проверять контрольные суммы на канальном
уровне; если только канальный уровень не может гораздо быстрее
запросить повторную передачу.

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

Короче, идея "всё время что-нибудь проверять" довольно глупа. Вместо
нее есть другая идея: "проверить как следует, но только один раз".  В
случае с обновлением пакетов это означает "проверять подпись
репозитория".  Если репозиторий прошел проверку и был криптографически
подписан, то все остальные проверки на клиенте уже абсолютно ничего не
добавляют.

> Если речь в первую очередь о сборочнице, то, возможно, стоит задуматься о
> патчинге apt-овых индексов (вместо генерации их с нуля).  Остальные
> клиенты gb-sh-rpmhdrcache вполне могли бы патчить то, что у них есть -- и
> генератор useful-files и генератор contents_index.
> Понятно, что единственной загвоздкой в патчинге индексов являются именно
> useful-files.

Зачем патчить аптовые индексы? Заново их создать - это несколько
секунд всего. Самая дорогая операция - это xz-сжатие, около минуты.
Для внутренних нужд надо мигрировать на другое сжатие, то есть на zstd
вместо xz.  У меня были работоспособные подвижки в этом направлении
еще осенью: https://github.com/svpv/apt-repo-tools/commit/64029fc8

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