☰

Стоит ли мне собирать приложение Haskell с помощью файла RPM SPEC или попытаться использовать (воспроизводимый) двоичный файл из конвейера CI?

tag-icon • tag-icon rpm
Стоит ли мне собирать приложение Haskell с помощью файла RPM SPEC или попытаться использовать (воспроизводимый) двоичный файл из конвейера CI?

Я не создавал RPM с нуля уже 20 лет. Так что можно сказать «никогда».

[править] Требование к RPM — обеспечить откат, контроль версий и т. п. Это не подлежит обсуждению.

У меня есть один бинарный файл и один файл конфигурации, которые мне нужно установить. Есть некоторая настройка с учетными записями пользователей и каталогами, которые должны быть выполнены, и я считаю, что это должно быть прямолинейно.

Если я хочу протестированную воспроизводимую сборку в процессе сборки RPM, мне придется повторить шаги нашего конвейера CI. Нетривиально. В идеале я могу просто вытащить нужные файлы из какого-то другого места:

%prep
cp ${somefile} ${another file} $RPM_SOURCE_DIR
%setup
:

Возможно ли это? Или я упускаю какое-то очевидное решение.

Спасибо.

решение1

С моей точки зрения, это во многом зависит от того, на что именно вы ориентируетесь:

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

Однако вы действительно можете просто извлечь готовые двоичные файлы и использовать их внутри файла спецификации для сборки пакета RPM, сокращенный пример для вашего сценария:

# […]
Source0: <binary file>
Source1: <config file>

# […]

%prep
%setup -q -c -T

%build

%install
install -D -p -m 0755 %{SOURCE0} $RPM_BUILD_ROOT%{_bindir}/%{name}
install -D -p -m 0644 %{SOURCE1} $RPM_BUILD_ROOT%{_sysconfdir}/%{name}.conf

# […]

Хотя это может сработать, вам следует явно проверить, подходят ли зависимости полученного пакета RPM ( rpm -qp --requires <…>.rpm) или отсутствуют зависимости времени выполнения. Часто при сборке пакета RPM есть параметры или параметры времени компиляции (например, CFLAGSили LDFLAGSпрограммное обеспечение, написанное на C), а также скрипты постобработки (например, /usr/lib/rpm/(redhat/)brp-*) при сборке пакета RPM, которые добавляют специфичные для дистрибутива вещи и/или извлекают зависимости времени выполнения для вас. Это может быть или не быть актуальным для вас (и некоторые скрипты постобработки также могут работать для предварительно собранных двоичных файлов, но другие не работают из-за отсутствия параметров компилятора). Хотя я упаковываю много программного обеспечения, у меня нет опыта работы с Haskell, но при просмотре некоторых пакетов Fedora есть пакеты RPM, имеющие зависимости времени выполнения (и если есть зависимости времени выполнения, они должны быть удовлетворены пакетами RPM, потому что именно так работает RPM; и недостаточно иметь соответствующую библиотеку где-то в вашей файловой системе, потому что RPM не будет знать о ней, если она не предоставлена ​​пакетом RPM). Таким образом, сборка RPM-пакета из готовых двоичных файлов может привести к созданию RPM-пакета без соответствующих зависимостей, что впоследствии может проявиться в виде ошибок во время выполнения.

Относительно приведенного выше примера: хотя SourceX:URL-адрес может быть указан, при сборке пакета RPM rpmbuildэти файлы все равно ожидаются на диске в SOURCESкаталоге (поэтому то, как они попадут в SOURCESкаталог, зависит от вас).

Поскольку вы не указали, на какой дистрибутив Linux вы ориентируетесь, я ссылаюсь на FedoraРуководство по упаковке Haskell здесь, что может дать или не дать дальнейшего вдохновения. И да, пакеты RPM могут быть кросс-дистрибутивными, что на практике часто приводит к статическим бинарникам внутри пакетов RPM из-за часто разных версий библиотек/пакетов в разных дистрибутивах Linux.

Связанный контент