Просмотр исходного текста страницы Блог:Точка Росы/Об использовании URL в метаданных RPM-пакетов

[[File:Dead-link.gif|256px|right]]

Как вы наверняка знаете, все программы в ROSA Linux распространяются в виде RPM-пакетов, включающих в себя архив с собственно файлами программы (скомпилированными исполнимыми файлами и библиотеками, данными и прочим добром), а также некоторые метаданные — имя пакета, его опиcание, зависимости и многое другое. В этой заметке мы остановимся на полях метаданных, содержащих ссылки на внешние ресурсы в сети Интернет.

В первую очередь это поле URL — ссылка на домашнюю страницу приложения, которую вы можете видеть при просмотре информации в менеджере пакетов. Кроме того, в spec-файлах (инструкциях для программы {{Prog|rpmbuild}} по сборке пакетов из исходного кода) большинства пакетов часто указывается ссылка на исходный код в апстриме, например:

 Source0: http://my-app.org/downloads/my-app-1.0.tar.gz

Чем полезны ссылки в таких полях и почему бы просто не указать имя архива с исходным кодом? Исконная причина заключается скорее всего в том, чтобы предоставить разработчику удобный способ скачать архив с той или иной версией программы — ведь знать домашнюю страничку — это хорошо, но нередко на этой страничке надо покопаться, чтобы добраться до архивов с исходным кодом. Если же ссылка уже указана в spec-файле, то для скачивания новой версии программы достаточно поменять {{File|my-app-1.0.tar.gz}} на {{File|my-app-2.0.tar.gz}} и скормить ссылку менеджеру закачек. Когда-то давно это надо было делать вручную, сейчас же наш {{Prog|rpmbuild}} способен сам скачивать файлы из интернета — так что для сборки новой версии программы вам достаточно поменять значение версии в spec-файле и запустить rpmbuild, все остальное будет сделано для вас автоматически.

Еще один используемый в РОСЕ инструмент, использующий данные о ссылках на исходный код — это {{Prog|Updates Tracker}}. Именно на основе анализа ссылок в spec-файлах этот инструмент определяет, где надо искать новые версии тех или иных программ.

Таким образом, ссылки на внешние источники в spec-файлах полезны и активно используются. Однако как и любые интернет-ресурсы, эти источники иногда меняют свое местоположение, а то и вовсе исчезают. Мэйнтейнерам пакетов необходимо отлавливать такие метаморфозы и соответсвующим образом обновлять метаданные, иначе пользователи будут отсылаться на несуществующие домашние страницы приложений, а Updates Tracker искать новые версии там, где их ожидать уже не стоит.

Для популярных пакетов, находящихся под пристальным вниманием мэйнтейнеров и регулярно обновляющихся, такой мониторинг происходит фактически в ручном режиме. Но в наших репозиториях немало пакетов, обновления которых выходят редко, либо которые нужны очень небольшому количеству пользователей и по этой причине не удостаиваются частого взгляда мэйнтейнера. К тому же ручное обновление метаданных имеет все недостатки, связанные с выполнением рутинных задач человеком — можно опечататься, что-то перепутать, забыть что-то обновить либо просто оставить старую информацию по причине лени или нехватки времени.

Способ борьбы с этими проблемами известен и заключается в автоматизации того, что ей хорошо поддается. А мониторинг актуальности ссылок и их обновление в эту категорию, безусловно, попадает. Впрочем, для работы с пакетами нам не нужны сложные веб-краулеры или трекеры сайтов — вместо этого, нам хотелось бы иметь специализированный инструментарий, способный находить мертвые ссылки в наших spec-файлах и по возможности заменять их на актуальные.

Способ написания подобных инструментов нам тоже хорошо известен — в этом году мы вновь воспользовались возможностью привлечь студентов [http://hse.ru НИУ ВШЭ] к выполнению полезных задач в рамках прохождения практики, в результате чего получили две утилиты — первая проверяет актуальность ссылок в заданном наборе spec-файлов, а вторая пробует угадать новую ссылку, если старая потеряла актуальность.

Первая утилита — [https://abf.rosalinux.ru/dsilakov/repo-checkers/blob/master/find_dead_links.sh find_dead_links] — действует прямолинейно, извлекая из spec-файлов все ссылки на внешние источники и проверяя их доступность (просто пытаясь к ним достучаться). На выходе получается список нерабочих ссылок для каждого пакета.

Вторая программа — [https://abf.rosalinux.ru/dsilakov/repo-fixers/blob/master/URLFixer.py URLFixer] — принимает на вход вывод {{Prog|find_dead_links}} и проводит его анализ, пытаясь определить — куда мог переехать тот или иной ресурс. Переезд домашних страниц на другие дислокации эта программа пока отловить неспособна (хотя с развитием поисковых систем эта задача не кажется такой уж нерешаемой), а вот с переездом архивов с исходным кодом вполне может справиться. Как показала практика, поломка ссылок на такие архивы часто вызвана довольно прозаическими причинами — например, разработчики могли удалить конкретную версию программы (заменив ее на более новую — в этом случае имеем явный сигнал мэйнтейнерам к обновлению пакета) или перепаковать архив в другой формат (в последнее время стало популярным переходить на использование xz). check_url проверяет, не произошел ли со сломавшейся ссылкой один из этих сценариев и пытается определить, на что следует заменить битую ссылку.

Казалось бы, в этих программах нет ничего сверхестественного (и их сложность вполне соответсвует двухнедельным усилиям пары студентов, практически не имевших опыта работы с Linux), но опыт их применения к репозиториям ROSA Desktop Fresh оказался впечатляющим — выяснилось, что некорректные ссылки содержались примерно в 500 пакетах (подавляющая часть которых находится в репозитори Contrib), а с помощью {{Prog|URLFixer}} удалось исправить около 80 % из них.

[[Category:ToROSAPoint]]
{{wl-publish: 2015-09-29 21:33:48 +0400 | Denis.silakov }}