RPM

2. Обзор

Первым делом разрешите мне изложить философию RPM. Одна из целей проектирования была в том чтобы позволить использовать ``безупречные'' исходные тексты. В RPP (нашей предыдущей системе пакетов от которой RPM не унаследовала ничего) исходные тексты были ``исправлены'', чтобы мы могли скомпилировать их. Теоретически кто-либо должен был установить исходные тексты с помощью RPP и собрать их без проблем. Но исходные тексты были не оригинальными и не было ссылок на то какие изменения мы сделали, чтобы заставить их работать. Некоторые люди загружали безупречные исходные тексты раздельно. В RPM мы имеем безупречные исходные тексты вместе с заплатками, которые используются для компиляции. Мы рассматриваем это как большое достижение. Для некоторых людей. если пришла новая версия программы, вам не нужно начинать с самого начала чтобы заставить ее скомпилироваться под RHL. Вы можете посмотреть на заплатку (patch), чтобы увидеть что вам необходимо сделать. Все значения по умолчанию для компиляции легко видны при этом способе.

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

Другое мощное свойство;-- это проверка пакетов. Если вы беспокоитесь о том, что вы удалили важный файл из некоторого пакета, просто проверьте это. Вы будете оповещены об любых аномалиях. С этой точки вы можете переустановить пакет, если это необходимо. Любые конфигурационные файлы будут сохранены.

Мы хотим отблагодарить людей из дистрибутивной группы BOGUS за множество их идей и концепций, которые включены в RPM. Хотя RPM был полностью написан Red Hat Software, его операции основаны на коде, написанном BOGUS (PM и PMS).

3. Основная информация

3.1 Получение RPM

Лучший способ получить RPM это установить Red Hat Linux. Если вы не хотите делать это, то вы все равно сможете получить и использовать RPM. Он мажет быть получен с ftp.redhat.com.

3.2 Требования RPM

Основное требование для запуска RPM это наличие cpio 2.4.2 или старше. Хотя эта система предназначена для использования в Linux, она может быть спокойно перенесена на другие Unix-системы. Она была скомпилирована на SunOS, Solaris, AIX, Irix, AmigaOS, и других. Будьте предупреждены, двоичные пакеты, сгенерированные на разных типах систем Unix не являются совместимыми.

Это минимальные требования для установки RPM. Для построения RPM из исходных текстов, вам также необходимо все обычно требуемое для построения пакета, подобно gcc, make, и т.п.

4. Использование RPM

В простейшей форме RPM может быть использован для установки пакетов:

rpm -i  foobar-1.0-1.i386.rpm

Следующая простая команда используется для удаления пакета:

rpm -e foobar

Одна из более сложных, но очень полезных команд позволяет вам устанавливать пакеты через FTP. Если вы подключены к сети и хотите установить новый пакет, все что вам нужно;-- это указать файл с правильным URL, примерно так:

rpm -i  ftp://ftp.pht.com/pub/linux/redhat/rh-2.0-beta/RPMS/foobar-1.0-1.i386.rpm

Заметим, что RPM запросит и/или установит через FTP.

Хотя это простые команды, RPM может быть использован множеством способов, как это видно из сообщения об использовании (Usage):

RPM version 2.3.9
Copyright (C) 1997 - Red Hat Software
This may be freely redistributed under the terms of the GNU Public License

usage: rpm {--help}
rpm {--version}
rpm {--initdb} [--dbpath <dir>]
rpm {--install -i} [-v] [--hash -h] [--percent] [--force] [--test]
[--replacepkgs] [--replacefiles] [--root <dir>]
[--excludedocs] [--includedocs] [--noscripts]
[--rcfile <file>] [--ignorearch] [--dbpath <dir>]
[--prefix <dir>] [--ignoreos] [--nodeps]
[--ftpproxy <host>] [--ftpport <port>]
file1.rpm ... fileN.rpm
rpm {--upgrade -U} [-v] [--hash -h] [--percent] [--force] [--test]
[--oldpackage] [--root <dir>] [--noscripts]
[--excludedocs] [--includedocs] [--rcfile <file>]
[--ignorearch] [--dbpath <dir>] [--prefix <dir>]
[--ftpproxy <host>] [--ftpport <port>]
[--ignoreos] [--nodeps] file1.rpm ... fileN.rpm
rpm {--query -q} [-afpg] [-i] [-l] [-s] [-d] [-c] [-v] [-R]
[--scripts] [--root <dir>] [--rcfile <file>]
[--whatprovides] [--whatrequires] [--requires]
[--ftpuseport] [--ftpproxy <host>] [--ftpport <port>]
[--provides] [--dump] [--dbpath <dir>] [targets]
rpm {--verify -V -y} [-afpg] [--root <dir>] [--rcfile <file>]
[--dbpath <dir>] [--nodeps] [--nofiles] [--noscripts]
[--nomd5] [targets]
rpm {--setperms} [-afpg] [target]
rpm {--setugids} [-afpg] [target]
rpm {--erase -e} [--root <dir>] [--noscripts] [--rcfile <file>]
[--dbpath <dir>] [--nodeps] [--allmatches]
package1 ... packageN
rpm {-b|t}[plciba] [-v] [--short-circuit] [--clean] [--rcfile <file>]
[--sign] [--test] [--timecheck <s>] specfile
rpm {--rebuild} [--rcfile <file>] [-v] source1.rpm ... sourceN.rpm
rpm {--recompile} [--rcfile <file>] [-v] source1.rpm ... sourceN.rpm
rpm {--resign} [--rcfile <file>] package1 package2 ... packageN
rpm {--addsign} [--rcfile <file>] package1 package2 ... packageN
rpm {--checksig -K} [--nopgp] [--nomd5] [--rcfile <file>]
package1 ... packageN
rpm {--rebuilddb} [--rcfile <file>] [--dbpath <dir>]
rpm {--querytags}

Вы можете найти больше информации о том, что какая опция обозначает, на справочной странице RPM.

5. Что я могу по-настоящему делать с RPM?

RPM - это очень полезная утилита, и, как вы видите, имеет различные опции. Лучший способ прочувствовать их - посмотреть на несколько примеров. Я привел простые примеры установки/удаления выше, так что здесь будет несколько больше примеров:

Допустим, вы случайно удалили некоторые файлы, но не уверены в том, что удалили. Если вы хотите проверить всю систему и просмотреть, что может отсутствовать, вы должны сделать:

rpm -Va

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

rpm -qf /usr/X11R6/bin/xjewel

Вывод должен быть:

xjewel-1.6-1

Вы нашли новый пакет RPM, но не знаете, для чего он. Для того чтобы найти некоторую информацию о нем, сделайте:

rpm -qpi koules-1.2-2.i386.rpm

Вывод должен быть:

Name        : koules                Distribution: Red Hat Linux Colgate
Version     : 1.2                   Vendor: Red Hat Software
Release     : 2                     Build Date: Mon Sep 02 11:59:12 1996
Install date: (none)                Build Host: porky.redhat.com
Group       : Games                 Source RPM: koules-1.2-2.src.rpm
Size        : 614939
Summary     : SVGAlib action game with multiplayer, network, and sound support
Description :
This arcade-style game is novel in conception and excellent in execution.
No shooting, no blood, no guts, no gore. The play is simple, but you
still must develop skill to play. This version uses SVGAlib to
run on a graphics console.

Теперь вы хотите посмотреть, какие файлы установит этот пакет. Вы должны сделать:

rpm -qpl koules-1.2-2.i386.rpm

Вывод будет:

/usr/doc/koules
/usr/doc/koules/ANNOUNCE
/usr/doc/koules/BUGS
/usr/doc/koules/COMPILE.OS2
/usr/doc/koules/COPYING
/usr/doc/koules/Card
/usr/doc/koules/ChangeLog
/usr/doc/koules/INSTALLATION
/usr/doc/koules/Icon.xpm
/usr/doc/koules/Icon2.xpm
/usr/doc/koules/Koules.FAQ
/usr/doc/koules/Koules.xpm
/usr/doc/koules/README
/usr/doc/koules/TODO
/usr/games/koules
/usr/games/koules.svga
/usr/games/koules.tcl
/usr/man/man6/koules.svga.6

Это только несколько примеров. Более творческие примеры могут быть придуманы легко, если вы подружитесь с RPM.

6. Построение пакетов RPM

Построение пакетов RPM достаточно просто, особенно если у вас есть программное обеспечение, которое вы хотите упаковать для своих нужд.

Основные шаги по созданию пакета RPM:

В большинстве случаев RPM создаст как бинарный пакет, так и пакет с исходным кодом.

6.1 Файл rpmrc

Настройка RPM осуществляется через файл /etc/rpmrc. Пример настроек:

require_vendor: 1
distribution: I roll my own!
require_distribution: 1
topdir: /usr/src/me
vendor: Mickiesoft
packager: Mickeysoft Packaging Account <packages@mickiesoft.com>
optflags: i386 -O2 -m486 -fno-strength-reduce
optflags: alpha -O2
optflags: sparc -O2
signature: pgp
pgp_name: Mickeysoft Packaging Account
pgp_path: /home/packages/.pgp
tmppath: /usr/tmp

Строка require_vendor обязывает RPM искать строку производителя. Эту информацию можно получить из файла /etc/rpmrc или из заголовка spec-файла. Чтобы деактивировать эту опцию, установите значение 0. Аналогично действуют строки require_distribution и require_group.

Следующая строка называется distribution. Её можно определить здесь или позднее в заголовке spec-файла. Если вы создаёте пакет для конкретного дистрибутива, рекомендуется убедиться в корректности этой строки. Строка vendor служит для аналогичных целей, но её значение может быть любым (например, "Joe's Software and Rock Music Emporium").

RPM также предоставляет возможность создания пакетов для разных архитектур. Файл rpmrc может содержать переменную optflags для сборки компонентов, требующих архитектурно-специфичных флагов. Подробности использования этой переменной описаны в следующих разделах.

Помимо вышеуказанных макросов, существуют и другие. Для просмотра текущих настроек и доступных флагов выполните:

rpm --showrc

6.2 Spec-файл

Начнем с рассмотрения spec-файла. Данный файл необходим для создания пакета. Spec-файл содержит описание программного обеспечения, инструкции по сборке пакета и список файлов для всех устанавливаемых компонентов.

Рекомендуется называть ваш spec-файл в соответствии со стандартным соглашением. Имя должно иметь следующий формат: имя_пакета-номер_версии-номер_выпуска.spec.

В качестве примера рассмотрим небольшой spec-файл (vim-3.0-1.spec):

Summary: ejects ejectable media and controls auto ejection
Name: eject
Version: 1.4
Release: 3
Copyright: GPL
Group: Utilities/System
Source: sunsite.unc.edu:/pub/Linux/utils/disk-management/eject-1.4.tar.gz
Patch: eject-1.4-make.patch
Patch1: eject-1.4-jaz.patch
%description
This program allows the user to eject media that is autoejecting like
CD-ROMs, Jaz and Zip drives, and floppy drives on SPARC machines.

%prep
%setup
%patch -p1
%patch1 -p1

%build
make RPM_OPT_FLAGS="$RPM_OPT_FLAGS"

%install
install -s -m 755 -o 0 -g 0 eject /usr/bin/eject
install -m 644 -o 0 -g 0 eject.1 /usr/man/man1

%files
%doc README COPYING ChangeLog
/usr/bin/eject
/usr/man/man1/eject.1

6.3 Заголовок

Заголовок содержит ряд стандартных полей, которые следует заполнить. При этом есть определенные требования к этим полям. Они должны быть заполнены следующим образом:

Указанные файлы должны располагаться в директории SOURCES. Структура директорий рассматривается в следующем разделе "Дерево директорий исходных текстов".

Patch: Здесь указывается местоположение патчей, которые вы можете захотеть загрузить вновь. Важно: имя файла должно соответствовать тому, которое вы использовали при создании вашего патча. Как и с файлами исходного кода, может быть несколько файлов патчей. Например:

Patch0: blah-0.patch
Patch1: blah-1.patch
Patch2: fooblah.patch

Эти файлы также должны находиться в директории SOURCES.

Copyright: Эта строка указывает, под какой лицензией распространяется пакет. Возможные варианты: GPL, BSD, MIT, public domain, distributable или commercial.

BuildRoot: С помощью этой строки можно задать "корневую" директорию для сборки и установки нового пакета. Это может быть полезно для тестирования пакета до его установки на вашем компьютере.

Group: Эта строка позволяет указать категорию для программы в иерархической структуре высокоуровневых установщиков (например, "glint" от Red Hat). Текущая иерархия групп выглядит так:

Applications 
Communications 
Editors 
Emacs 
Engineering 
Spreadsheets 
Databases 
Graphics 
Networking 
Mail 
Math 
News 
Publishing 
TeX 
Base 
Kernel 
Utilities 
Archiving 
Console 
File 
System 
Terminal 
Text 
Daemons 
Documentation 
X11 
XFree86 
Servers 
Applications 
Graphics 
Networking 
Games 
Strategy 
Video 
Amusements 
Utilities 
Libraries 
Window Managers 
Libraries 
Networking 
Admin 
Daemons 
News 
Utilities 
Development 
Debuggers 
Libraries 
Libc 
Languages 
Fortran 
Tcl 
Building 
Version Control 
Tools 
Shells 
Games

Хотя это и не является частью заголовка, данный раздел следует описывать вместе с остальными элементами заголовка. Необходим один тег описания для каждого пакета или подпакета. Этот многострочный тег предназначен для детального описания содержания пакета.

6.4 Раздел Prep

Этот раздел является вторым в spec-файле. Он служит для подготовки исходных кодов к сборке. В этом разделе следует производить все необходимые изменения и настройки в исходном коде, аналогичные тем, которые требуются для выполнения команды make.

Важное замечание: каждый из этих разделов на самом деле представляет собой место для выполнения shell-скриптов. Вам просто нужно написать sh-скрипт и разместить его после тега %prep для распаковки и модификации исходного кода. Тем не менее, для вашего удобства были добавлены макросы.

Первым из этих макросов является макрос %setup. В своей базовой форме (без параметров) он распаковывает исходные тексты и переходит в директорию с исходными текстами. Он также поддерживает следующие опции:

-n name: задает имя директории, в которой будет производиться сборка пакета, как "name". Значение по умолчанию — $NAME-$VERSION. Другие возможные значения включают $NAME, ${NAME}${VERSION} или то, что указано в основном файле архива. (Обратите внимание, что переменные с символом "$" в этом контексте не являются реальными переменными, доступными в spec-файле. Они используются здесь в качестве примеров. В вашем пакете следует использовать реальные имена и версии, а не эти переменные).

-c: создает указанную директорию перед распаковкой архивов.

-b #: выполняет распаковку Source# до перехода в директорию. Эта опция игнорирует -c, так что использование ее не рекомендуется. Эта опция полезна только при наличии нескольких исходных файлов.

-a #: выполняет распаковку Source# после перехода в директорию.

-T: отключает действие по умолчанию по распаковке исходных текстов и требует использования опций -b 0 или -a 0 для распаковки основного файла исходных текстов. Эта опция необходима, если у вас есть дополнительные исходные файлы.

-D: предотвращает удаление директории до распаковки. Эта опция полезна только при наличии нескольких макросов setup. Данная опция должна использоваться только в макросах setup, следующих за первым (но никогда не в первом).

Следующий из имеющихся макросов — это макрос %patch. Он служит для автоматизации процесса применения патчей к исходным кодам. У этого макроса есть несколько опций, описанных ниже:

#: применяет Patch# в качестве файла патча.

-p #: определяет количество директорий, которые следует игнорировать для команды patch(1).

-P: это действие по умолчанию, которое применяет Patch (или Patch0). Этот флаг отключает действие по умолчанию и требует указания 0 для применения основного файла с исходными кодами. Эта опция полезна во втором (и последующих) макросах %patch, если требуется указание номера, отличного от номера в первом макросе.

Также возможно использовать %patch# вместо команды: %patch # -P.

Это все необходимые вам макросы. Как только вы правильно все настроите, вы можете производить дополнительные настройки, используя sh-скрипты. Все действия, выполняемые до макроса %build (рассматриваемого в следующем разделе), выполняются с помощью sh. См. предыдущий раздел, чтобы узнать, какие действия вы можете выполнить по желанию.

6.5 Раздел Build

В этом разделе макросы отсутствуют. Вам следует разместить команды, которые необходимо выполнить для сборки программного обеспечения после распаковки исходников, внесения изменений и перехода в соответствующую директорию. Этот раздел представляет собой набор команд для sh, так что вы можете использовать любые команды этой оболочки, включая комментарии. Имейте в виду, что текущая рабочая директория в каждом из этих разделов устанавливается в корневую директорию исходников.

6.6 Раздел Install

Этот раздел также не содержит макросов. Здесь необходимо указать команды для установки. Если ваш пакет поддерживает команду make install, просто добавьте ее. В противном случае вы можете модифицировать makefile или выполнять установку вручную с помощью команд sh. Считайте, что ваша текущая директория является корневой для исходников пакета.

6.7 Опциональные скрипты, выполняемые до и после установки/удаления пакета

Вы можете добавить скрипты, которые будут выполняться до и после установки или удаления бинарного пакета. Основная цель таких скриптов — выполнение действий типа запуска ldconfig после установки или удаления пакета, содержащего общие библиотеки. Макросы для каждого из этих скриптов представлены ниже:

%pre — макрос для выполнения скрипта перед установкой.

%post — макрос для выполнения скрипта после установки.

%preun — макрос для выполнения скрипта перед удалением пакета.

%postun — макрос для выполнения скрипта после удаления пакета.

Содержимым разделов должны быть любые sh скрипты, хотя вам не нужно определять строку #!/bin/sh.

6.8 Раздел Files

В этом разделе вы должны указать файлы, предназначенные для бинарного пакета. У RPM нет возможности автоматически определить, какие бинарные файлы были установлены в результате выполнения команды make install. Действительно, нет такой функции. Некоторые рекомендуют использовать команду find до и после установки, но это неприемлемо на многопользовательских системах. Другие файлы могут быть созданы во время процесса сборки пакета, которые не связаны с пакетом напрямую.

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

%doc — обозначает документацию в исходных файлах пакета, которую вы хотите установить при установке. Документация будет размещена в директории /usr/doc/$NAME-$VERSION-$RELEASE. Вы можете указать несколько документов для этого макроса или применить макрос к каждому документу отдельно.

%config — обозначает конфигурационные файлы пакета. Это могут быть файлы типа sendmail.cf, passwd и другие. Если вы в дальнейшем удалите пакет, содержащий конфигурационные файлы, все неизмененные файлы будут удалены, а измененные будут переименованы, добавив к имени файла расширение .rpmsave.

%dir — указывает на отдельную директорию, которую пакет считает своей. По умолчанию, если директория указана БЕЗ макроса %dir, то ВСЕ содержимое этой директории будет включено в список файлов и затем установлено как часть пакета.

%files -f <filename> — позволяет вам задать список файлов в отдельном файле внутри директории с исходными текстами. Это особенно удобно, когда пакет может автоматически генерировать свой собственный список файлов. Таким образом, вы не должны вручную перечислять каждый файл.

Важно быть внимательным при указании директорий. Если вы ошибочно укажете, например, /usr/bin, ваш бинарный пакет будет содержать все файлы этой директории на вашей системе.

6.9 Построение пакета

Создание патча (заплатки) основано на различиях между оригинальными исходниками и теми, которые вы модифицировали. Пример команды, которая создаёт патч:

diff -uNr dirname.orig dirname > ../SOURCES/dirname-linux.patch

Обратите внимание, что в названии патча слово "linux" — это лишь идентификатор. Вы можете использовать что-то более конкретное, например "config" или "bugs", чтобы лучше описать причину создания этой заплатки. Рекомендуется также проверить файл заплатки перед использованием, чтобы убедиться, что туда случайно не попали бинарные файлы.

Создание списка файлов

Теперь, когда у вас есть готовые исходники и вы знаете, как их собирать и устанавливать, составьте список файлов на основе результатов установки для дальнейшего использования в spec-файле. Многие специалисты формируют spec-файл параллельно выполнению всех описанных выше шагов. Вы можете начать с создания основы файла, дополняя его по мере продвижения по этапам создания пакета.

Сборка пакета с использованием RPM

Как только у вас готов spec-файл, вы можете начать сборку вашего пакета. Пример команды для сборки:

rpm -ba foobar-1.0.spec

Существуют и другие полезные параметры для ключа -b:

Существует несколько модификаторов к переключателю -b:

6.10 Тестирование пакета

После создания двоичного пакета и пакета с исходным кодом, вам следует его проверить. Лучший способ это сделать — протестировать пакет на другой машине, отличной от той, на которой производилась сборка. После всего вам, вероятно, потребуется выполнить несколько команд make install на вашей машине, так что все необходимое будет установлено.

Вы можете выполнить rpm -u packagename для тестирования пакета, но это может быть обманчиво. Ведь в процессе создания пакета вы выполняли команду make install. Если вы что-то пропустите в списке файлов, это не будет удалено при установке. При повторной установке двоичного пакета все на вашей системе будет корректно, но сам пакет может быть неполным. Помните, что если вы использовали команду rpm -ba package, большинство пользователей будет устанавливать ваш пакет при помощи команды rpm -i package. Убедитесь, что вы не выполняете ничего лишнего в разделах build или install, что должно будет быть сделано только при установке двоичного пакета.

6.11 Что делать с вашим новым пакетом RPM

После создания вашего собственного пакета RPM (предполагая, что аналогичного пакета в формате RPM ещё нет), вы можете поделиться своей работой с другими. При условии, что ваш пакет распространяется свободно, вы можете рассмотреть возможность загрузки его на сервер ftp.redhat.com.

6.12 Что дальше?

Ознакомьтесь с предыдущими разделами "Тестирование пакета" и "Что делать с вашим новым пакетом RPM". Мы стремимся сделать доступными как можно больше качественных пакетов RPM. Пожалуйста, уделите время тщательному тестированию пакетов и загрузке их в общий доступ. Убедитесь, что загружаете только свободное программное обеспечение. Коммерческие продукты и shareware не следует загружать, пока они не имеют явного авторского разрешения. Это касается программного обеспечения, такого как Netscape, ssh, pgp и других.

7. Создание RPM для различных архитектур

На данный момент RPM можно использовать для создания пакетов для Intel i386, Digital Alpha под управлением Linux и Sparc. Также сообщалось о работе RPM на SGI и рабочих станциях HP. Есть несколько функций, облегчающих создание пакетов для различных платформ. Одной из них является директива "optflags" в файле /etc/rpmrc, позволяющая устанавливать флаги компиляции для определенной архитектуры. Ещё одна полезная функция — это макрос "arch" в spec-файле, который позволяет выполнять различные действия в зависимости от архитектуры сборки. Кроме того, в заголовке есть директива "Exclude".

7.1 Простой spec-файл

Ниже представлена часть spec-файла для пакета "fileutils". Он настроен для создания как на платформе Alpha, так и на Intel.

Summary: GNU File Utilities
Name: fileutils
Version: 3.16
Release: 1
Copyright: GPL
Group: Utilities/File
Source0: prep.ai.mit.edu:/pub/gnu/fileutils-3.16.tar.gz
Source1: DIR_COLORS
Patch: fileutils-3.16-mktime.patch

%description
These are the GNU file management utilities. It includes programs
to copy, move, list, etc, files.

The ls program in this package now incorporates color ls!

%prep
%setup

%ifarch alpha
%patch -p1
autoconf
%endif
%build
configure --prefix=/usr --exec-prefix=/
make CFLAGS="$RPM_OPT_FLAGS" LDFLAGS=-s

%install
rm -f /usr/info/fileutils*
make install
gzip -9nf /usr/info/fileutils*

7.2 Директива Optflags

В этом примере иллюстрируется использование директивы "optflags" из файла /etc/rpmrc. В зависимости от той архитектуры, на которой производится сборка, соответствующее значение присваивается переменной RPM_OPT_FLAGS. Вам следует модифицировать Makefile вашего пакета для использования этой переменной, заменяя тем самым директивы, которые вы могли бы использовать (например, директивы -m486 и -O2). Для лучшего понимания можете скачать данный пакет с исходным кодом, извлечь исходные тексты и ознакомиться с Makefile. Изучив патч для Makefile, вы поймете, какие изменения необходимо внести.

7.3 Макросы

Макрос %ifarch имеет большое значение. Довольно часто возникает необходимость внести определенные изменения или применить заплатки, специфичные только для одной архитектуры. В таких случаях RPM позволяет применять эти изменения или заплатки исключительно для этой архитектуры.

В приведенном выше примере, fileutils имеет заплатку для 64-битовых машин. Очевидно, что она должна быть применена только для Alpha. Поэтому мы добавляем макрос %ifarch вокруг применения 64-битовой заплатки следующим образом:

%ifarch axp
%patch1 -p1
%endif

Это гарантирует, что заплатка будет применена только для архитектуры alpha.

7.4 Исключение архитектур из пакетов

Для возможности поддержки пакетов с исходным кодом в одной директории для всех платформ, мы внедрили функционал "исключения" сборки пакетов для конкретных архитектур. Таким образом, вы можете продолжать выполнять команды вроде:

rpm --rebuild /usr/src/SRPMS/*.rpm

и получать корректно собранные пакеты. Если вы ещё не портировали приложение на определённую платформу, всё, что вам нужно сделать — это добавить строку:

ExcludeArch: axp

в заголовок spec-файла пакета с исходным кодом. После этого пересоберите пакет на платформе, на которой он может быть собран. Таким образом, у вас будет пакет с исходным кодом, который может быть собран на платформе Intel, но будет корректно пропущен при сборке на платформе Alpha.

Заключение

Использование RPM для создания мультиплатформенных пакетов, как правило, проще, чем адаптация самого пакета под разные платформы. Как всегда, когда возникают сложности, полезно посмотреть, как реализован аналогичный пакет.