dsilakov: 28 September

On 28.09.2014 16:53, Egor Kochetoff wrote:
> Добрый день, Денис!
>
> Нам нужно немного сведений, чтобы сделать программу по высшему разряду.
> Вот например, какой Ваш второй инициал для титульного листа ТЗ? И Ваша должность — туда же.

Силаков Д.В., начальник отдела Технологических разработок и сопровождения

>
> Как должны выглядеть отчёты? Если это будет yaml-файл в указанной в конфиге папке — нормально? Или надо json? html?
yaml - ok.

> Имеются ли какие-то сформулированные требования к быстродействию? Мы себе не очень представляем, в каких терминах их формулировать, а писать в ТЗ «чтоб работала с приемлемой скоростью» совершенно бессмысленно.

Смотри - нам необходимо анализировать достаточно много репозиториев; как минимум, все репозитории из этих папок:
http://mirror.rosalab.ru/rosa/rosa2014.1/repository/
http://mirror.rosalab.ru/rosa/rosa2012lts/repository/
http://mirror.rosalab.ru/rosa/server/6.5/repository/
http://mirror.rosalab.ru/openmandriva/openmandriva2014.0/repository/
http://mirror.rosalab.ru/openmandriva/cooker/repository/

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

В идеале, весь анализ надо уложить в несколько часов - поскольку он выполняется как часть более общего набора тестов (которые лежат на http://fba.rosalinux.ru/), и хотелось бы, чтобы все эти тесты проходили за ночь (~12 часов). А там и без того немало "тяжелых" вещей (например, rpmlint).

> А ещё: обязательно ли использовать питон?
> Потому что можно сделать так (используя /bin/bash):
> nm -Cu для всех исполнимых файлов с выводом результатов в соответствующие файлы
> uniq ото всех полученных файлов с формированием результата в выходной файл requires-all
> nm -Cg для всех библиотек и аналогично собрать все в список provides-all.
> Потом grep -Fxvf provides-all requires-all
>
> Ну и если найдутся такие requires, для которых нет provides, то детально формировать отчёт об ошибке.
> Для всего этого bash удобней питона — меньше кода, его логичней использовать для вызова внешних программ.

> Или есть какие-то требования к встраиванию программы как модуль питона куда-нибудь? Если да, то какие?
>

А оно сейчас так и реализовано. Можешь тут глянуть, например:
https://abf.io/dsilakov/repo-checkers

И главное требование, с которым bash и grep радикально не справляются - это быстродействие.

Во-первых, невозможно проанализировать все репозитории "с нуля" - куча времени уходит просто на распаковку rpm-пакетов. Поэтому там сейчас реализована некоторая инкрементность - результаты "nm" для пакета складываются в файл, и при повторном запуске идет проверка - если такой файл для пакета уже есть, то пакет вооще не распаковывается.

Но даже с такой инкрементальностью возникают сложности - иметь дело с десятками тысяч файлов уже непросто, тут напрашивается какая-нибудь база данных. Например, если есть 100.000 файлов с данными от nm в одной директории, то ФС начинает притормаживать. И даже если на обработку одного файла (проверку того, что он есть, и  считывание данных из него) мы затратим 0.1 секунды, то на 100.000 файлов у нас уйдет ~2.5 часа. Плюс grep на таких объемах данных работает очень не быстро и кушает кучу ресурсов. Вплоть до того, что может быть убит ядром.

Оценки грубые, но реальность такова, что при текуем подходе с использованием bash и nm мы вынуждены разносить проверки разных репозиториев по дням недели - посмотри на файл https://abf.io/dsilakov/repo-checkers/blob/master/launch_tests.sh, там есть такие сообщения - "Skipping - not today".

В принципе, были пробные попытки использовать sqlite, но как-то до дела не дошло.

В принципе, против bash возражений. Но есть ощущение, что данные лучше складывать не в файлы, а в базу данных, и отчеты строить средствами sql, а не grep.

> PS. Ну и ещё маленький вопрос: есть ли требования к формату конфига? Подойдёт ли yaml или bash (как /etc/bashrc)?
>

нет, никаких требований. Как удобно, так и делаете.