7.9 KiB
Сборка eopkg пакета
Официальная документация по сборке пакетов eopkg для последующего размещения в официальном репозитории.
Процесс сборки
Предварительная подготовка
Для начала необходимо сконфигурировать файл packager, который используется для упаковщика в результирующем двоичном пакете. Для этого в домашней директории необходимо создать каталог .solus с содержащим внутри себя файлом packager:
mkdir ~/.solus
nano ~/.solus/packager
Внутри файла необходимо указать два ключа, идентифицирующие собирающего пакеты:
[Packager]
Name=Your Name Here
Email=your.email@address
Следующим действием необхоимо произвести установку базового инструмента разработки system.devel:
sudo eopkg install -c system.devel
Для сборки eopkg пакетов необходимо использовать инструмент solbuild:
sudo eopkg it solbuild
Если нужно использовать только unstable репозиторий по умолчанию, также установить конфигурацию для нестабильного репозитория solbuild-config-unstable:
sudo eopkg it solbuild-config-unstable
Если нужно использовать только local репозиторий по умолчанию, также установить конфигурацию для локального нестабильного репозитория:
sudo eopkg install solbuild-config-local-unstable
Также понадобятся git и arcanist:
sudo eopkg it git arcanist
После установки необходимо инициализировать solbuild:
sudo solbuild init
Это займет некоторое время, так как будет производиться загрузка и подготовка образа. Рекомендуется обновлять solbuild, в противном случае обновления будут применяться при каждой сборке:
sudo solbuild update
Следующим шагом необходимо создать каталог для разработки, в котором будет находиться все конфигурационные файлы для сборки пакетов. К примеру, в домашней директории создать каталог building:
mkdir ~/building
Далее внутри каталога building произвести настройку инструментов для сборки. Нужно настроить common (набор сценариев создания), который позволяет более легко управлять, создавать, проверять и публиковать пакеты. Для этого нужно клонировать общий репозиторий с помощью git:
cd ~/building
git clone https://dev.getsol.us/source/common.git
Далее нужно настроить символические ссылки:
ln -sv common/Makefile.common .
ln -sv common/Makefile.toplevel Makefile
ln -sv common/Makefile.iso .
В результате выполненных действий каталог building примет следующий вид:
├── common
├── Makefile
├── Makefile.common
└── Makefile.iso
Использование локального репозитория
После выполнения установки solbuild-config-local-unstable создаётся путь /var/lib/solbuild/local/ локального репозитория. При использовании локального репозитория необходимо выполнить индексацию списка:
sudo eopkg index --skip-signing /var/lib/solbuild/local/ --output /var/lib/solbuild/local/eopkg-index.xml
Стоит заметить, что в своей работе eopkg всегда будет отдавать предпочтение пакетам из самого верхнего репозитория, указанного в списке eopkg lr. Другими словами - если пакет существует как в локальном репозитории solbuild, так и в официальном вышестоящем репозитории Solus, eopkg будет рассматривать только пакет из первого репозитория, указанного в eopkg lr, независимо от его номера выпуска.
Для того, чтобы изменить порядок следования репозиториев (их приоритетов) необходимо передобавить их в нужном порядке, например:
sudo eopkg ar Local /var/lib/solbuild/local/eopkg-index.xml.xz
sudo eopkg ar Solus https://mirrors.rit.edu/solus/packages/unstable/eopkg-index.xml.xz
Таким образом локальный репозиторий будет иметь высокий приоритет для eopkg:
eopkg lr
Local [active]
/var/lib/solbuild/local/eopkg-index.xml.xz
Solus [active]
https://mirrors.rit.edu/solus/packages/unstable/eopkg-index.xml.xz
Стоит обратить внимание, что пакеты, отсутствующие в локальном репозитории сборки solbuild, будут извлечены из вышестоящего официального репозитория Solus (unstable). Индексацию eopkg необходимо обновлять всякий раз, когда добавляется или удаляется локально созданные пакеты в локальном репозитории solbuild – в противном случае eopkg не будет знать, что новые пакеты доступны/были удалены из репозитория.
Подготовка сборки пакета
Все пакеты создаются из одного файла сборки, который предоставляет все необходимые метаданные для менеджера пакетов, а также этапы упаковки, необходимые для создания пакета. Это соответствует спецификации YAML.