Существует ли путь к пакетам тестов, которые я создаю для корректных зависимостей?
Я абсолютно плохо знаком с упаковкой, поэтому простите мне, если я прошу у чего-то очевидного опытного поставщика программного блока...
Как я могу быть уверен, что упомянул все зависимости правильно в моем пакете?
Скажите, что мое приложение использует lib library-xyz который не установлен по умолчанию. Если я создаю пакет и устанавливаю его на моей машине разработки, library-xyz уже будет установлен, таким образом - даже если мне не удалось упомянуть это как зависимость - программа будет все еще работать правильно. Но другой пользователь на новой установке человечности не будет иметь library-xyz установленный и программа, вероятно, откажет для него.
Путем я тестирую, теперь имеет новую установку человечности, работающую в VM и устанавливающую пакет там, но так как он походит на типичную проблему, интересно, существует ли лучший способ протестировать, что-то принимающее ту же философию chroot но это - вместо того, чтобы "исключить" части файловой системы "отключило" бы все те установленные пакеты, которые не являются "значением по умолчанию" в чистой установке человечности.
Я упаковываю программы Python.
2 ответа
lintian прогоны программы после создания использования пакета debuild и должен предупредить Вас для недостающих библиотек при создании двоичного пакета. ldd команда может использоваться для проверки, какие библиотеки необходимы для пакета.
Я использую ниже сценария для выборки зависимостей от пакета библиотеки быстро:
#!/bin/sh
# Save it as executable ~/bin/pkglibs
# Usage: pkglibs directory
# pkglibs file
list_lib_pkgnames() {
local lib="$1" libs
# get the libraries for given "$lib", stripping out linker libraries
libs=$(ldd "$lib" | awk '/=/{print $1}' | grep -vE '^(linux-vdso|linux-gate)\.so\.1$')
# if there are libraries, find the matching packages for it
[ -n "$libs" ] && dpkg -S $libs | sed 's/: .*//'
}
search="$1"
if [ -d "$search" ]; then
# for directories, recursively search for library dependencies
find "$search" -type f -exec "$0" {} \; | sort -u
else
list_lib_pkgnames "$search"
fi
Команда может требовать времени для больших каталогов начиная с него, тестируют каждый файл separatedly. Это может быть оптимизировано для генерации списка библиотек сначала и затем передачи уникальных записей в dpkg -S команда, но это - осуществление для читателя.
Пример: pkglibs /usr/lib/mesa/:
ia32-libs
lib32gcc1
lib32stdc++6
libc6
libc6-i386
libdrm2
libgcc1
libstdc++6
libx11-6
libxau6
libxcb1
libxdamage1
libxdmcp6
libxext6
libxfixes3
libxxf86vm1
Как объяснено в моем комментарии выше оценки pbuilder, это полезно главным образом проверить зависимости от сборки (подобный для загрузки пакета на панель запуска PPA), но не будет полезно проверить зависимости, если Вы не добавляете некоторые дополнительные шаги в своих упаковочных сценариях как рабочие модульные тесты.
Другое аналогичное решение (запущенные тесты в ограниченной среде), если бы Вы просто рассматриваете зависимости против библиотек Python, состояло бы в том, чтобы создать virtualenv так, чтобы Вы управляли библиотеками Python, доступными во время тестирования. Один инструмент, который был бы полезен для управления виртуальными средами с помощью нескольких версий Python при запущении тестов, будет токсикологией.
Это не добавит зависимости для Вас в debian/control файл, но могло быть полезным так или иначе.