Сборка проприетарного пакета с нуля

Данное руководство покажет, как правильно собрать пакет RPM в Sisyphus с нуля в инфраструктуре Gear и git.alt, не имея исходного кода пакета, на примере пакета StarBoardSoftware.

Входные требования

• Желательно иметь локальное зеркало Сизифа.
• Установленный и немного настроенный hasher.
• Пакет, который необходимо пересобрать для Сизифа.
• Ну, и самое главное, желание этим заниматься.

Исследование пакета

Первым делом нужно исследовать пакет на его кривость.

Для начала смотрим список файлов, которые появляются после установки пакета: rpm -qlp StarBoardSoftware-9.2.i586.rpm | less.

И видим, что все файлы ставятся в каталог /usr/local/.

Попытка установить пакет

Пробуем поставить этот пакет в hasher, на голую систему:

• hsh --initroot-only -v ~/hasher
• hsh-install -v `pwd`/StarBoardSoftware-9.2.i586.rpm

Следующие пакеты имеют неудовлетворенные зависимости:
  StarBoardSoftware: Требует: perl(strict) но пакет не может быть установлен
E: Извините, `битые' пакеты

Удовлетворение зависимостей

Ладно, создаём фиктивный пакет со следующим спеком в ~/RPM/SPECS/:

Name: perl-strict
Version: 1.0
Release: alt1
Provides: perl(strict)
BuildArch: noarch
Summary: perl(strict)
Group: Test
License: test
%description
%files
%changelog

Выполняем rpmbuild -bb perl-strict.spec

Обрабатываются файлы: perl-strict-1.0-alt1
Provides: perl(strict)
Записан: /home/becase/RPM/RPMS/noarch/perl-strict-1.0-alt1.noarch.rpm

Ставим наш самособранный пакет в hasher: hsh-install -v `pwd`/perl-strict-1.0-alt1.noarch.rpm

Вторая попытка установки

Второй подход к установке: hsh-install -v `pwd`/StarBoardSoftware-9.2.i586.rpm

Получаем вывод:

>>> preinst start
PARAMETERS 1 
/root/tmp/rpm-tmp.92646: line 36: rmmod: command not found
<<< preinst end
error: unpacking of archive failed on file /: cpio: utime failed - Operation not permitted
hsh-install: Packages installation failed.

Из этого следует, что пакет перед установкой пытается выполнить какой-то скрипт preinst, далее нам не позволяют устанавливать корень системы.

Смотрим rpm -qlp StarBoardSoftware-9.2.i586.rpm | less head -n5

/
/usr
/usr/local
/usr/local/HitachiSolutions
/usr/local/HitachiSolutions/StarBoard

Да, действительно почему-то авторы исходного пакета решили упаковать корень.

Запускаем mc mc, смотрим содержимое пакета, входя в него, как в архив. В частности, нас интересуют действия, выполняемые в сценариях установки. Они находятся в INFO/SCRIPTS/ во внутренностях пакета. Смотрим скрипты, ужасаемся и решаем, что ни в коем случае не следует устанавливать этот пакет как есть.

Зато видим, что в пункте postinstall выполняется команда /usr/local/StarBoardSoftware/installation-scripts/install.sh binary uspace app. Здесь-то и находится вся логика установки!

Извлечение файлов из пакета

Достаём файлы из пакета без установки: rpm2cpio StarBoardSoftware-9.2.i586.rpm | cpio -i Как мы и ожидали, у нас появился каталог usr.

Для удобства дальнейшей работы упаковываем этот каталог в tar-архив: tar -cvf starboard_usr.tar usr

Исследование лицензии

Также исследуем файлы на предмет наличия лицензии. Находим ./usr/local/StarBoardSoftware/Resources/documents/COPYING, который содержит GPLv2. Также находим файл ./usr/local/StarBoardSoftware/Resources/documents/license/ru/license.rtf, который содержит следующие строки:

Передавать Программное обеспечение и все права по данному Соглашению
третьей стороне вместе с копией данного Соглашения, если третья
сторона соглашается принять положения и условия данного Соглашения.
Если Вы передаете Программное обеспечение, Вы должны или одновременно
передать третьей стороне все копии в печатной или машиночитаемой
форме, включая все модификации и части Программного обеспечения,
содержащиеся в других программах или объединенные с ними, или
уничтожить все непереданные копии. 

Значит, можно пакет пересобрать для Сизифа.

Под лицензией GPLv2 поставляется драйвер для доски StarBoard, будем считать, что он уже собран. В отличии от других систем, в ALTLinux скомпилированный драйвер ядра ставится в /lib/modules/`uname -r`/lsadrv/lsadrv.ko.

Автоматизация установки

Для множественных попыток установить этот софт в hasher создаём сценарий автоматизации.

#!/bin/sh -x

#Корневой каталог системы в hasher
root=$HOME/hasher/chroot

#Корневой каталог программы
sroot=/usr/local/StarBoardSoftware

#Каталог с файлом starboard_usr.tar
archive_dir=/media/disk/ALTLinux/left/starboard2010/StarBoardSoftware

#Имя созданного нами архива
archive_name=starboard_usr.tar

#Префикс для запуска команды под фиктивным рутом в hasher
prefix="hsh-run --rooter -- "

#Пересоздание системы в hasher
hsh --initroot-only -v ~/hasher

#Список установки, будет дополняться, желательно как можно более приближающий систему в hasher к реальной
install_list="kernel-modules-lsadrv-std-def"

#Ставим в hasher пакеты из нашего списка
hsh-install -v $install_list

#Копируем наш архив в подкаталог фиктивного корня системы
rsync --progress --inplace $archive_dir/$archive_name $root/.in/

#Запускаем от фиктивного рута установку файлов в фиктивный корень
$prefix tar -xvf $archive_name -C /

#Удаляем архив, чтобы не занимал место
rm -f $root/.in/$archive_name

#Запускается сценарий, в котором будут исправляться установочные сценарии
. starboard-fix-install-script

#Создаём файлы, в которых будет храниться списки файлов до запуска скрипта и после
touch $root/.out/filelist.1 $root/.out/filelist.2
#Создаём от имени "рута" каталог, в котором будем хранить копию настроек системы
$prefix mkdir /.res
#Копируем содержимое настроек системы
$prefix cp -ar /etc /.res/etc
#Получаем список файлов до работы скрипта
$prefix find / > $root/.out/filelist.1

#Запускаем скрипт, что-то вытворяющий с системой, которую нам не жалко
$prefix $sroot/installation-scripts/install.sh

#Получаем список файлов после работы скрипта
$prefix find / > $root/.out/filelist.2
#Получаем список, отражающий, что этот скрипт натворил
diff -Nau $root/.out/filelist.1 $root/.out/filelist.2 > $root/.out/files.diff
#И как повлиял на содержимое файлов настройки
$prefix diff -Naur /.res/etc /etc > $root/.out/etc.diff

Ошибки сценария:

/usr/local/StarBoardSoftware/installation-scripts/install.sh: line 318: [: =: unary operator expected
/usr/local/StarBoardSoftware/installation-scripts/install.sh: line 326: $DEFAULTSLIST: ambiguous redirect

Смотрим, что добавилось:

grep '+/' hasher/chroot/.out/files.diff

Что-то подозрительное:

+/tmp/fxduo.driver.build.log
+/etc/ld.so.conf.d/lsadrv.conf
+/lib/modules/2.6.35-std-def-alt9/kernel/drivers/usb/input

Выходит, что во время установки сценарий пытался скомпилировать драйвер и поставить его в /lib/modules/2.6.35-std-def-alt9/kernel/drivers/usb/input, но у него это не вышло. И ещё он решил добавить каталог поиска системных библиотек в /etc/ld.so.conf.d/lsadrv.conf, что не может не вызвать подозрение на нарушение целостности системы.

Смотрим, что там такое: cat hasher/chroot/etc/ld.so.conf.d/lsadrv.conf

/usr/local/lsadrv/lib

{{cmd|ls hasher/chroot/usr/local/lsadrv/lib}

libborqt-6.9.0-qt2.3.qm.ja  liblsadev.so        liblsdrv.so        libQtCore.so      libQtCore.so.4.5.2  libQtGui.so.4.5
libborqt-6.9.0-qt2.3.so     liblsadev.so.0      liblsdrv.so.2      libQtCore.so.4    libQtGui.so         libQtGui.so.4.5.2
libborqt-6.9-qt2.3.so       liblsadev.so.0.0.0  liblsdrv.so.2.0.0  libQtCore.so.4.5  libQtGui.so.4

Наличие в /usr/local/lsadrv/lib библиотек Qt может пагубно повлиять на системные Qt-программы, если этот путь будет использоваться системой.