Порты OpenBSD: руководство по тестированию

OpenBSD Порты - руководство по тестированию [Порты - На главную]

Введение
Тестирование
Комментирование
И снова тестирование

Введение

Дерево портов это колоссальная работа, результат которой позволяет каждому пользоватю OpenBSD исользовать third party программы без необходимости тратить время на изучение тонкостей их работы, внесение необходимых изменений (с целью запустить программы именно в среде OpenBSD), конфигурацию и установку. Вся эта работа проделывается группой волонтеров, кто тратит время и силы на портирование и тестирование приложений в OpenBSD.

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

Работа над новыми портами ведется в -current; нет никакой гарантии, что новые порты или их обновления будут корректно работать в других версиях (branches). Это значит, что вы должны обновить свою систему и дерево портов до -current. Инструкцию, где описывается как это сделать, можно найти на странице посвященной current. Также рекомендуется подписаться на рассылки ports и ports-changes. Это поможет быть в курсе новых изменений в дереве портов и их обновлений.

Тестирование

В почтовых рассылках есть два типа материалов: новые порты и обновления. О новых портах как правило сообщается в письмах, к которым прикрепляются архив (tarball) или ссылка на него. Хорошей идеей будет распаковать его в каталоге /usr/ports/mystuff/ и протестировать там. Обновления как правило представляют из себя diff для дерева портов в -current. Лучше всего скопировать порт в mystuff/ и использовать diff, чтобы предотвратить поломку всего дерева. Если установлена предыдущая версия порта, рекомендуется удалить ее перед сборкой более новой версии, чтобы избежать побочных эффектов, таких как символы, отсутствующие в более старой версии библиотеки.

Необходим процесс пошаговой сборки, чтобы быть уверенным, что каждый target, смотри ports(7), правильно собран (achieved correctly):

fetch
- Необходим, чтобы удостовериться, что все необходимые для порта файлы (distfile(s)) могут быть корректно загруженны. Попробуйте протестировать все указанные MASTER_SITES, чтобы убедиться, что все они являются рабочими (valid sources).
checksum
- Проверьте, что у всех загруженных distfiles совпадают checksums, с теми, которые находятся в distinfo файле. Вы можете повторно запустить make clean=dist && make makesum и убедиться, что ничего не изменилось.
extract
- Target prepare запускается автоматически до extract. Его задача - установить все {BUILD,LIB}_DEPENDS для этого порта (такие как bzip2).
patch
- При использовании патчей не должно быть никаких warnings. Процесс должен проходить гладко, без каких-либо проблем.
- В каталоге patches/ не должно оставаться никаких ".orig" файлов.
- Другой распространенной ошибкой является включение в патч тегов RCS; это сломает порт, когда он будет добавлен в репозиторий, а тег RCS будет развернут.
configure
- Проверьте, что скрипт configure правильно определяет окружение (features) на вашей платформе.
- Скрипт configure не должен обнаруживать случайных приложений, уже установленных в вашей системе, без явных настроек зависимостей, заданных в порту.
- Если порт не собирается с помощью libtool из base, вы можете попробовать установить USE_LIBTOOL=gnu, которая использует исправленную версию (patched version) из портов. GNU libtool печально известен своими нежелательными «возможностями» в OpenBSD, поэтому, если порт не собирается с помощью libtool из base, это должно быть исправлено, а в исходниках порта должен быть комментарий о том, почему в порте используется Makefile.
- Если порт использует CMake, и вы видите нежелательные результаты на этом этапе, обязательно проверьте или отправьте следующие файлы дополнительно:
  - ${WRKBUILD}/CMakeCache.txt
  - ${WRKBUILD}/CMakeFiles/CMakeError.log
  - ${WRKBUILD}/CMakeFiles/CMakeOutput.log
build
- Не должно быть никаких ошибок сборки (build errors) и подозрительных warnings.
- Warnings касательно tmpnam(3) должны решаться при помощи mkstemp(3).
- Установите для переменной SEPARATE_BUILD значение 'Yes' и попробуйте после этого пересобрать порт снова. Все должно работать.
- Удостоверьтесь, что зависимости от GNU make действительно необходимы.
test
- Проверьте на наличие ошибок (empty tests means okay).
- Если у тестов есть зависимости, отличные от указанных в {BUILD,RUN}_DEPENDS, убедитесь, что TEST_DEPENDS определен правильно.
fake
- Эта target устанавливает приложение в поддельный (fake) рабочий каталог, чтобы гарантировать, что все файлы могут быть легко упакованы без влияния/эффектов на базовую часть системы.
- Порт никогда не должен устанавливать свои файлы вне fake-каталога, например в /usr/local.
- При использовании GNU libtool иногда возникают проблемы с перекомпоновкой библиотек во время fake-процесса на некоторых архитектурах.
- Проверьте, что все файлы после установки имеют правильного владельца (ownerships) и и правильные права доступа (permissions).
port-lib-depends-check
- Это проверит, все ли библиотеки, от которых зависит порт, могут быть найдены/доступны через LIB_DEPENDS или WANTLIB. Результат должен быть пустым. Перечисленные выше переменные следует проверять, когда вы видите строки, начинающиеся с «Extra» или «Missing».
package
- Собрка пакета может быть поломана, если pkg/PLIST* и/или pkg/PFRAG* неправильны.
install
- Пакеты должны установить все файлы из своих списков успешно и с правильными правами доступа. Будьте особенно осторожны с файлами, у которых установлен бит setuid.
- Убедитесь, что скрипт INSTALL, принадлежащий пакету, делает именно то, что должен, и ни в коем случае ничего (ни одного файла) не перезаписывает в /etc.
deinstall
- Это должно удалять все файлы, установленные пакетом, за исключением тех, что в /etc.
- Системные файлы, созданные пакетом во время выполнения, должны быть помечены как @extra и/или @extraunexec в pkg/PLIST*.

Оставшиеся pkg/ файлы, такие как DESCR и MESSAGE, должны быть проверены на грамматику и опечатки. Абзацы должны быть отформатированы с использованием fmt(1) по 80 символов на строку.

Комментирование

В конце теста наконец-то действительно важная вещь: комментарии. Даже если порт работает нормально, комментарии должны быть сделаны. Если у нас есть десять комментариев, в которых люди говорят, что порт работает нормально под разными архитектурами, то добавление порта в репозиторий произойдет быстрее. Если что-то не работает, то соответствующая информация должна быть предоставлена. Есть инструменты, которые могут помочь в на этом этапе, например portslogger(1), который похож на «интеллигентный tee(1)», который перенаправляет вывод в log-файл.

Пример:

# make install 2>&1 | /usr/ports/infrastructure/bin/portslogger .

Это перенаправит вывод в log-файл, находящийся в этом же каталоге.

Наконец, как только будет установлено, что порт исправен, следует проверить и другие порты, зависящие от него, чтобы убедиться, что и они по-прежнему работают правильно. Target show-required-by поможет найти другие порты, которые зависят от него.

И снова тестирование

Проверьте Makefile порта на правильные зависимости, опечатки, неправильные ссылки, бесполезные или отсутствующие переменные, правильное лицензирование и категорию. Те, кто более опытен, могут помочь, изучив патчи, а также предоставив diff для исправления ошибок или других улучшений.

Эти diff(s) должны быть сделаны с опциями -uNprx CVS. cvs diff -uNp также можно использовать для создания патчей для CVS репозитория.