#bass 

meta4ra зависимость в BASS

В ad98892e99f95d6eabac4bd20ac804c7bd919adb упоминал, что в принципе от
meta4ra утилит можно избавиться за счёт переписывания всякого на shell
и Perl. Не то чтобы они меня напрягали (я же их сам и написал), но
как-то с избавлением от обязательных .meta4 файлов уже выглядят
избыточными.

И добил это. Теперь BASS может вообще без них. Пока они в prepare-deps
ещё устанавливаются, но потому что это обычные Go программы, а Go всё
равно собирается из-за goredo. Хотя в принципе можно бы было
использовать любой redo (поддерживающий базовую совместимость) и Go
вообще не собирать. Пока написал это предложение, вспомнил про detpax
(7687e77d7a77d0a14e4dd38c79886b942199ac9d), так что пока нужен.

Обнаружил, что по POSIX tee можно указать множество файлов. Поэтому
сделать распараллеленный расчёт хэшей в shell проще простого. Делаем
кучу mkfifo, запускаем процессы расчёта хэшей в фоне, вызываем tee на
созданные FIFO, делаем wait, радуемся. meta4ra-hash должен быть
поэффективнее за счёт того, что не создаёт всякие временные файлы, но
это уже мелочи.

Написал аналог meta4ra-check на shell. Который, тоже на shell, сам
поймёт какие хэшеры у нас вообще доступны, найдёт общий знаменатель с
хэшами предоставленными в hashes файлах, запустит соответствующие
команды. В крайнем случае, какой-нибудь sha512 из коробки есть в любой
ОС, насколько помню. Утилита, кстати, будет использовать meta4ra-check
если он установлен -- просто как оптимизация.

А из всего этого последовало то, что теперь можно использовать хоть
fetch, хоть wget, хоть curl, хоть продолжать meta4ra-dl -- всё
автоматически определится и будет использоваться в цикле для скачивания
URL-ов, проверяя контрольные суммы уже shell утилитой.

Во время установки пакетов, была предусмотрена вероятность отсутствия
meta4ra-check утилиты, и тогда выдавалось предупреждение что контрольные
суммы пакета не будут проверяться. Теперь же в этом надобности нет.

    [оставить комментарий]