Хитрости работы с Yum и RPM — CentOS Wiki

Советы по работе с Yum и RPM

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

1. Отображение типа архитектуры в получаемом RPM

Эту простую мелочь довольно легко выполнить, и она будет очнь полезна людям, использующих x86_64 системы. Одна строка в файле ~/.rpmmacros спасет от неприятностей в дальнейшем.

 

echo "%_query_all_fmt %%{name}-%%{version}-%%{release}.%%{arch}" >> ~/.rpmmacros

 

2. Запрос пакетов не из CentOS

Хотите получить список пакетов установленных из сторонних репозиториев, не CentOS?

 

rpm -qa —qf '%{NAME} %{VENDOR}\n' | grep -v CentOS

 

3. Сбросить права доступа на файлы

У вас возникла полная неразбериха с правами доступа на файлы в пакете? Не беда, RPM об этом позаботится.

 

rpm —setperms

 

4. Просмотр изменений

Поскольку CentOS и исходный поставщик кода выпускают обновления безопасности, номера версий могут ввести в заблуждение, когда вы смотрите на CVE исправления. Проверка наличия изменений в пакете есть хороший способ увидеть — внесены ли исправления или нет. И снова RPM приходит на помощь.

 

rpm -q —changelog | less

 

Использование 'less' не является обязательным, но для некоторых пакетов, таких как ядро, изменения могут быть довольно обширными. Поэтому данное дополнение делает вывод более читабельным.

5. Где документация?

Чтобы быстро получить документацию, связанную с пакетом, вы можете использовать следующие два варианта:

 

rpm -qd

 

• Это покажет вам документацию, содержащуюся в этом rpm. Если у вас есть только название файла то:

 

rpm -qdf /path/to/file

 

• и rpm покажет вам документацию в пакете, который владеет этим файлом.

6. Происхождение пакета

Иногда хочется знать, где вы получили пакет или пакеты, сколько в вашей системе пакетов от конкретного репозитория или поставщика. Есть несколько параметров поиска, которые можно использовать. Хотя они не 100% совершенны, тем не менее они могут помочь. Большинство пакетов из репозиториев имеют теги с идентификатором в строке Release. Например rpmforge использует rf в качестве идентификатора. Вы можете использовать это, чтобы посмотреть, что у вас установлено оттуда:

 

rpm -qa release="*rf*"

 

а если вы хотите увидеть, как много пакетов у вас установлено от Johnny Hughes-а можно использовать:

 

rpm -qa packager="Johnny*"

 

Этот метод работает на большинстве категорий вида rpm -qi

 

rpm -qa

Данная команда выдаст весь список установленных пакетов.

7. Извлечение только одного файла

Если вам нужно извлечь только один файл из rpm без переустановки всего пакета, вы можете сделать это с rpm2cpio. Например, чтобы извлечь только один файл из logrotate rpm, используйте следующее:

 

rpm2cpio logrotate-1.0-1.i386.rpm |cpio -ivd etc/logrotate.conf

 

8. Запрос даты установки пакета

Полезно после обновления найти старые пакеты, которые не были обновлены.

 

rpm -qa —last >~/RPMS_by_Install_Date

 

Можно использовать 'less' для вывода, чтобы найти все RPMS старше, чем дата установки. Используя также grep — конкретизировать пакеты и дату установки.

9. Запрос имеющихся пакетов из репозитория

Найти все пакеты, доступные из определенного репозитория, например RPMforge. Пакеты уже установленные из этого репозитория показываться не будут.

 

yum —disable "*" —enable "rpmforge" list available

 

10. Поиск с помощью YUM в репозитории пакета по заданной строке

Поиск пакетов, содержащих нужную строку в названии или описании пакета.

 

yum search buildrpmtree | less

 

11. Использование Yum с прокси-сервером

Для того чтобы заставить Yum работать через прокси-сервер необходимо добавить следующий параметр в /etc/yum.conf:

 

proxy=http://yourproxy:8080/

 

где — yourproxy это имя прокси-сервера, а 8080 это порт прокси-сервера. Если сервер требует аутентификации, вы можете указать логин как:

 

proxy=http://username:password@yourproxy:8080/

 

RPM Package Manager позволяет использовать прокси-переменные среды. Это может быть задано в /etc/profile или специфизированно для конкретного пользователя в файле ~/.bash_profile::

 

export http_proxy=http://yourproxy:8080/ export ftp_proxy=http://yourproxy:8080/

 

Для использования wget через прокси-сервер, добавте следующие строки в /etc/wgetrc

 

http_proxy = http://yourproxy:8080/ ftp_proxy = http://yourproxy:8080/

 

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

12. Использование Yum для установки локального пакета, автоматически проверяя и удовлетворяя зависимости

 

yum —nogpgcheck localinstall packagename.arch.rpm

 

13. Получение и пересборка пакета, не будучи при этом root-ом

Иногда вам просто необходимо пересобрать определенный пакет — возможно, лишь добавить конфигурационные опции, которые просто не существуют в основном пакете. Или потому, что вы нашли необходимый пакет, который отсутствует в репозитории, а на сайте разработчика RPMs для другого дистрибутива. Таким образом, вы должны получить src.rpm и востановить его под себя. Но в действительности вы не хотите делать этого в качестве суперпользователя. Итак, как пересобрать свои пакеты в вашей домашней директории под собственной учетной записью.

13.1 Метод А

Для начало необходимо настроить каталог для работы. Он имеет довольно полное сходство по структуре с каталогом /usr/src/redhat:

 

[testuser@shutdown ~]$ cd [testuser@shutdown ~]$ mkdir -p redhat/{SRPMS,RPMS,SPECS,BUILD,SOURCES} [testuser@shutdown ~]$ ls redhat/ BUILD RPMS SOURCES SPECS SRPMS [testuser@shutdown ~]$

 

С помощью rpm макроса произведем подмену, для того чтобы rpmbuild узнал о нас и о том что нужно собрать:

 

[testuser@shutdown ~]$ echo "%_topdir /home/testuser/redhat" >> .rpmmacros [testuser@shutdown ~]$ echo "%packager Test User " >> .rpmmacros [testuser@shutdown ~]$ cat .rpmmacros %_topdir /home/testuser/redhat %packager Test User [testuser@shutdown ~]$

 

Именно так. Следующее действие — задание rpmbuild-у —rebuild foo.src.rpm, результат работы будет в файле ~/redhat/RPMS/i386 (или та архитектура с которой вы строили пакет).

13.2 Метод Б

Для CentOS-4, настроить репозиторий kbs-Extras repo (опционально добавить kbs-Misk) со страницы репозиториев и 'yum install fedora-rpmdevtools' под root-ом используя 'sudo' или 'su -'. Завести юзера (возможно вы захотите использовать специальный аккаунт для того, чтобы избежать проблем в своей обычной домашней директории) и выполнить "fedora-buildrpmtree" и ~/rpmbuild/…в дереве каталогов и ~/.rpmmacros файл будет автоматически создан. (Примечание "rpmbuild" против "RedHat" в методе А.)

Для CentOS-5 — пакет rpmdevtools отсутствует в наличии. В FC6 SRPM rpmdevtools-5.3-1.fc6.src.rpm собирается и работает.

Ниже представлен макрос для получения надлежащих имен некоторых пакетов (замените соответствующую версию дистрибутива для "el4" на свою):

 

[testuser@shutdown ~]$ echo "%dist .el4" >> .rpmmacros

 

14. Отображение приоритетов для всех установленных репозиториев

Вы можете получить список всех установленных у вас репозиториев — yum repolist all. Однако, он не показывает индекс приоритета. Вот строка необходимая для этого. Если номер не определен, по умолчанию, это самый низкий приоритет (99).

 

cat /etc/yum.repos.d/*.repo | sed -n -e "/^\[/h; /priority *=/{ G; s/\n/ /; s/ity=/ity = /; p }" | sort -k3n

 

15. Yum получить список пакетов по заданному словосочетанию

[root@isp ~]# yum list 'vim*' Installed Packages vim-minimal.i386 2:7.0.109-7.el5 installed Available Packages vim-X11.i386 2:7.0.109-7.el5 base vim-augeas.i386 0.9.0-2.el5.rf rpmforge vim-clustershell.noarch 1.5.1-1.el5 epel vim-common.i386 2:7.0.109-7.el5 base vim-enhanced.i386 2:7.0.109-7.el5 base vim-halibut.i386 1.0-2.20100504svn8934.el5.1 epel vim-puppet.noarch 2.7.9-1.el5.rf rpmforge

16. Показать все установленные ключи GPG

Показать список всех ключей с соответствующей информацией репозитория:

rpm -q gpg-pubkey —qf '%{name}-%{version}-%{release} —> %{summary}\n'

17. Подпись пакетов

Вы хотите подписать свой пакет, который собрали, чтобы другие могли убедится в его достоверности? Вы можете это сделать достаточно просто. Воспользуйтесь документацией Fedora RPM packaging guide.

Примечание: для CentOS 5 и 4, будет лучше, если вы будете использовать для подписи ключ DSA (так как для версии 4 RSA были выявлены проблемы с подтверждением).

18. Метапакеты YUM

Метапакет — это специальный пакет, не содержащий никакого программного обеспечения, но имеющий в зависимостях определенный набор софта. Например: установка X-ов на сервер.

Чтобы посмотреть список всех метапакетов, необходимо выполнить команду: yum grouplist. Но если у вас стоит русская локаль, то список будет выдан на русском языке. Чтобы получить список пригодный для установки (на английском), задайте язык вывода команды на английском:

LANG=C yum grouplist

19. Как вывести список установленных пакетов

Установленные пакеты могут показать команды

yum list installed

или

rpm -qa

 

Пример, порлучить список установленных пакетов из репозитория IUS:

[root@centos-6 ~]# yum list installed | grep ius php71u-cli.x86_64      7.1.17-1.ius.el6 @ius                                     php71u-common.x86_64   7.1.17-1.ius.el6 @ius                                     php71u-embedded.x86_64 7.1.17-1.ius.el6 @ius                                     php71u-fpm.x86_64      7.1.17-1.ius.el6 @ius                                                            7.1.17-1.ius.el6 @ius                                     php71u-gd.x86_64       7.1.17-1.ius.el6 @ius                                     php71u-intl.x86_64     7.1.17-1.ius.el6 @ius                                     php71u-json.x86_64     7.1.17-1.ius.el6 @ius                                     php71u-mbstring.x86_64 7.1.17-1.ius.el6 @ius                                     php71u-pdo.x86_64      7.1.17-1.ius.el6 @ius                                                            3.4.3-2.ius.el6  @ius                                     php71u-pgsql.x86_64    7.1.17-1.ius.el6 @ius                                     php71u-xml.x86_64      7.1.17-1.ius.el6 @ius                                     php71u-xmlrpc.x86_64   7.1.17-1.ius.el6 @ius

 

Yellow Dog Updater, Modified (Yum) — это менеджер пакетов по умолчанию, используемый в CentOS (все версии). Он используется для установки и обновления пакетов из CentOS (и сторонних) репозиториев.

 

 

Используйте утилиту yum для изменения программного обеспечения в вашей системе:
— Чтобы установить новое программное обеспечение из репозиториев пакетов.
— Чтобы установить новое программное обеспечение из отдельного файла пакета.
— Чтобы обновлять существующее программное обеспечение в вашей системе.
— Чтобы удалять ненужное программное обеспечение из вашей системы.

Yum реализован как библиотека на языке программирования Python, с небольшим набором программ, которые представляют интерфейс командной строки. Также существуют оболочки на основе GUI, такие как Yum Extender (yumex). В настоящее время разрабатывается переписывание yum на основе libsolv с именем DNF и заменяет yum как диспетчер пакетов по умолчанию в Fedora 22.

В качестве полной замены своего предшественника — инструмента Yellowdog Updater (YUP), yum развивался в первую очередь для обновления и управления системами Red Hat Linux, используемыми в Отделе физики Университета Дьюка(Северная Каролина, США). Сет Видал и Майкл Стэннер разработали yum, в то время как yup первоначально разрабатывался и поддерживался Дэном Бурко, Брайаном Стиллвелом, Стивеном Эди и Трой Бенгегердес из Yellow Dog Linux. В 2003 году Роберт Г. Браун в университете Дьюка опубликовал документацию. В дальнейшем yuь включили в Red Hat Enterprise Linux, Fedora, CentOS и многие другие дистрибутивы Linux на основе RPM, включая сам Yellow Dog Linux, где он заменил исходную утилиту YUP, которая в прошлом обновлялась на SourceForge в 2001 году. К 2005 году он, по оценкам, был доступен на более чем половине рынка Linux.

Общая публичная лицензия GNU от yum разрешает бесплатное и свободное распространение программного обеспечения с открытым исходным кодом без каких-либо роялти, если соблюдаются другие условия лицензии.

Установка пакетов в CentOS 7

Сэт Видал продолжал вносить свой вклад в yum до тех пор, пока он не погиб в результате велосипедной аварии в Дареме, штат Северная Каролина, 8 июля 2013 года.

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

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

Для поиска установленных пакетов используются опции list, search, provide.
С помощью опции list выполняется поиск пакета по его названию. Пример:

# yum list package_name

Можно воспользоваться подстановкой значения с помощью символа *, экранируя его с помощью символа \ :

# yum list packagen\*

Вместо * можно использовать знак ?, который заменяет один любой символ в поиске:

# yum list mysq\?
Available Packages
mysql.x86_64 5.1.73-3.el6_5 updates

Поиск пакета в репозиториях по его имени (возможно по неполному слову) и в его описании:

# yum search squid
squid.x86_64 : The Squid proxy caching server
squidguard.x86_64 : Combined filter, redirector and access controller plugin for squid
squidguard-blacklists.noarch : Regularly updated blacklists for use with squidguard
calamaris.noarch : Squid native log format (NLF) analyzer and report generator
sarg.x86_64 : Squid usage report generator per user/ip/name

Опция provides используется для поиска пакета, содержащего указанный в поиске файл/каталог. К примеру, требуется узнать к какому пакету относится файл httpd.conf:

# yum provides */httpd.conf
httpd-2.2.15-15.el6.centos.1.i686 : Apache HTTP Server
Repo : base

Как установить пакет в CentOS:

# yum install mc

Можно указать несколько пакетов для установки, разделяя их пробелами.
Что бы YUM не запрашивал подтверждения установки пакета и/или его зависимостей — используйте ключ -y:

# yum -y install mc

Как переустановить пакет в CentOS:

# yum reinstall packagename

Как установить rpm-пакет в CentOS:

# yum localinstall nginx-2.25.i386.rpm

Как обновить установленный пакет в CentOS:

# yum update packagename

Как обновить все пакеты в CentOS:

# yum update

Как посмотреть список всех установленных в системе пакетов:

# yum list installed

Как посмотреть список установленных пакетов, которые можно обновить:

# yum check-update

Как выполнить downgrade пакета до его предыдущей версии:

# yum downgrade packagename

Как удалить установленный пакет из системы:

# yum remove packagename

YUM и репозитории
Показать список активных репозиториев из каталога /etc/yum.repos.d/ :

# yum repolist

Показать список всех (в том числе и неактивных) репозиториев из каталога /etc/yum.repos.d/ :

# yum repolist all

Получить информацию об установленных пакетах:

# yum info

О конкретном пакете:

# yum info packagename

Как исключить пакет из списка пакетов для обновления:
— открыть для редактирования файл /etc/yum.conf, и в него добавить строку:

exclude=packagename,packagename2

Как просмотреть список зависимостей пакета:

# yum deplist packagename

Посмотреть список последних действий YUM:

# yum history

Сервисные команды менеджера пакетов YUM

Как очистить кеш YUM:

# yum clean all

Пересоздать кеш:

# yum makecache

Как посмотреть список пакетов по дате их установки/обновления:

# rpm -qa —last | less

Создание RPM пакетов из исходников

Дата: 25 февраля 2011

Данная статья описывает процесс создания RPM пакетов на примере Fedora.

RPM пакеты имеют собственную структуру, отличную от других. Но зачем создавать свои RPM, если можно просто скомпилировать исходники? Ответ на этот вопрос в рутинной установке, а также помощи разработчикам Fedora или другим дистрибутивам. Устанавливая каждый раз одни и те же программы из исходников, можно написать скрипт для автоматизации этого, однако, если есть RPM, то не надо тратить много времени на установку, также как и необходимая программа будет постоянно доступна онлайн из репозитория (конечно же, если вы ее туда отправите).

Итак приступим к подготовке рабочей среды для создания RPM.

# yum groupinstall «Development Tools»
# yum install rpmdevtools
На данной стадии происходит установка необходимых утилит и различных библиотек разработчика.

НИКОГДА НЕ СОЗДАВАЙТЕ RPM ОТ ROOT! (это может нарушить работу системы, увеличить возможность взлома и так далее)

После окончания установки, запустите

rpmdev-setuptree
Это приведет к создание ветки директорий
BUILD BUILDROOT RPMS SOURCES SPECS SRPMS

Из всех директорий нас интересует только SOURCES SPECS, информация в остальных, если все сделано верно, сгенерируется автоматически.

Теперь нам нужен .spec файл, примеры можно найти путем стачивания .src.rpm с репозитория, после распаковки, будет .spec файл, который необходимо поправить под наши нужды.

Сами исходники с патчами или без, копируем в SOURCES.

Когда все готово, запускаем компилирование и создание RPM

rpmbuild -ba ПУТЬ/NAME.spec для создания .src.rpm
rpmbuild -bi ПУТЬ/NAME.spec для создания бинарника или просто .rpm

Для установки и/или тестирования

# rpm -ivh sourcepackage-name*.src.rpm
или
# rpm -ivh package-name*.rpm
Если все сделано правильно, то программа установится с предупреждением, что rpb database изменена сторонней программой (правильно, мы же ее еще не залили на Fedora сервер).

Объяснение часто используемых областей в .spec файле

Name: Базовое имя пакета удовлетворяющее требованиям Packagen Naming Guidelines. После этого, макрос %{name} будет обращаться к данному разделу.

Version: Номер версии, при использовании даты в версии, используйте формат, гг.мм (пример 11.02). %{version} для последующего обращения к данной области.

Release: Должно быть 1%{?dist}, таким образом, число будет увеличиваться каждый раз, когда создается пакет для одной и той же версии дистрибутива.

Summary: Краткое описание пакета.

Group: Существующая группа пакетов, например Applications/Databases.

Чтобы узнать весь список
# less /usr/share/doc/rpm-*/GROUPS
Для документации будет соответственно группа Documentation.

License: Лицензия на программу, обязана быть для открытых исходников, например «GPLv2+» (GPL версии 2 или новее). Для нескольких лицензий используйте «and» или «or» «GPLv2 and BSD». Следует указывать лицензию максимально точно, можно указывать несколько лицензий с помощью «and» и «or», например «GPLv2 and BSD».

URL: Ссылка на сайт программы/проекта.

Source0: Ссылка на архив с исходным кодом. Если указана полная ссылка, то одноименный пакет должен быть в папке SOURCES. Если источников исходного кода несколько, то используем Source1, Source2 и т.д.

Patch0: Название первого патча для программы, имя файла должно заканчиваться на .patch и лежать в директории ~/rpmbuild/SOURCES. Патчей может быть несколько.

BuildArch: Архитектура программы под определенные процессоры. Для универсальных пакетов «noarch».

BuildRoot: Место, выделенное для компиляции и установки исходников приложения во время выполнения процесса «%install». По стандарту Fedora, будет создана специальная директория в /var/tmp.

Установка пакетов в CentOS 7

Более новые версии RPM пропустят это значение и поместят build root в %{_topdir}/BUILDROOT/

BuildRequires: Список необходимых приложений для сборки пакета (через запятую). Автоматически не определяются. Некоторые стандартные приложения могут быть опущены в данном списке. Полный список приложений, которые могут быть пропущены здесь (https://fedoraproject.org/wiki/Packaging/Guidelines).

Requires: Список необходимых приложений для работы после установки (через запятую). В большинстве случаев определяются автоматически rpmbuild.

%description: Описание программы, строки не должны быть длиннее 80 символов.
%prep: Скрипты для подготовки программы, распаковки и подготовки к сборке.
%build: Скрипты для сборки программы, компиляции и подготовки к установке.
%test: Скрипты для тестирования программы, выполняются после %build, но до %install.
%install: Скрипты для установки программы, команды скопируют файлы из «build directory» %{_builddir} (которая находится ~/rpmbuild/BUILD) в директорию buildroot %{buildroot}, которая обычно находится в /var/tmp.
%clean: Инструкции для очистки buildroot, например,
rm -rf %{buildroot}
%files: Список устанавливаемых файлов.
%changelog: Изменения в программе.

//xenos88

Статья подготовлена опираясь на официальный источник от Fedora

NextPreviousContents

---

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

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

Основные процедуры чтобы построить пакет RPM следующие:

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

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

6.1 Файл rpmrc

Настройка RPM доступна через файл . Пример выглядит подобно:

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

Следующая строка это строка . Вы можете определить ее здесь или позже в заголовке spec-файла. При построении пакета для особого дистрибутива это хорошая идея убедиться что строка правильна, даже хотя она требуется. Строка обозначает тоже самое, но может быть чем угодно (например, Joe’s Software and Rock Music Emporium).

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

В добавление к вышеприведенным макросам, существует еще несколько. Вы можете использовать:

чтобы увидеть какие значения установлены у вас и какие флаги доступны.

6.2 Spec-файл

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

Вы можете захотеть назвать ваш spec-файл согласно стандартному соглашению. Имя должно быть следующим: имя пакета-тире-номер версии-тире-номер выпуска (релиз)-точка-spec.

Здесь приведен маленький spec-файл (vim-3.0-1.spec):

6.3 Заголовок

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

• Это однострочное описание пакета.
• Это должна быт строка имени из имени файла rpm, котрое вы планируете использовать.
• Это должна быть строка версии из имени файла rpm, которое вы планируете использовать.
• Это номер выпуска для пакета с той же самой версией (например, если мы сделали пакет и обнаружили, что он незначительно неисправный и нам необходимо сделать его заново, то следующий пакет будет номер выпуска 2).
• Это имя файла иконки, которое будет использоваться другими высокоуровневыми утилитами установки (подобными «glint» из Red Hat). Она должна быть в формате gif и располагаться в директории SOURCES.
• Эта строка указывает на расположение «ДОМА» файла исходных текстов. Она используется если вы хотите получить исходные тексты снова и проверить новые версии. Предостережение: Имя файла в этой строке ДОЛЖНО соответствовать имени файла который вы имеете на своей собственной системе (например не изменяйте имя загруженного файла исходных текстов). Вы можете также указать больше чем один файл исходных текстов используя следующие строки: Эти файлы должны находиться в директории . (Структура директорий обсуждается далее в разделе «Дерево директорий исходных текстов»).
• Это место где вы можете найти заплатки, если вы захотите загрузить их снова. Предостережение: Имя файла должно соответствовать имени файла которое вы использовали когда делали вашу заплатку. Вы можете также заметить, что вы можете иметь много файлов заплаток также как вы можете иметь много файлов исходных текстов. У вас должно быть что-то подобное: Эти файлы должны быть в директории .
• Эта строка говорит с какими авторскими правами идет пакет. Вы можете использовать что-то подобное GPL, BSD, MIT, public domain, distributable, или commercial.
• Эта строка позволяет вам указать директорию как «корневую» для построения и установки нового пакета. Вы можете использовать это для тестирования вашего пакета до установки его на вашей машине.
• Эта строка используется чтобы указать высокоуровневым программам установки (таким как «glint» Red Hat) где разместить эту отдельную программу в их иерархических структурах. Дерево груп в настоящее время выглядит примерно так:
• В действительности это не часть заголовка, но этот раздел должен быть описан вместе с остальными частями заголовка. Вам нужен один таг описания на один пакет и/или подпакет. Это многостроковое поле, которое должно использоваться чтобы дать достаточно полное описание пакета.

6.4 Раздел Prep

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

Одно замечание: Каждый из этих разделов в действительности просто место для выполнения скриптов оболочки. Вы должны просто сделать -скрипт и поместить его после тага для распаковки и исправления ваших исходных текстов. Однако мы добавили макросы чтобы помочь вам сделать это.

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

• установит имя директории где будет производиться построение пакета в . Значение по умолчанию равно . Другие возможные значения включают , , или что использует главный файл архива. (Заметим, что эти переменные с «$» не являются настоящими переменными доступными внутри spec-файла. Они просто используются здесь вместо имен примеров. Вам необходимо использовать настоящие имена и версии в вашем пакете, а не эти переменные).

  Отличный способ загрузки пакета с rpm без установки на RHEL

• создаст указанную директорию до выполнения распаковки архивов.
• будет выполнять распаковку Source# до выполнения cd в директорию (и это делает нечувствительной к опции так что не делайте ее). Это полезно только в случае множества файлов исходных текстов.
• будет выполнять распаковку Source# после перехода в директорию.
• Эта опция отменяет действия по умолчанию при распаковке исходных текстов и требует опций или чтобы произвести разархивацию главного файла исходных текстов. Вам нужно это в случае наличия дополнительных файлов исходных текстов.
• Не удалять директорию до распаковки. Это полезно только когда вы имеете больше одного макроса setup. Эта опция должна использоваться только в макросах setup после первого (но никогда не быть в первом макросе).

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

• будет прикладывать Patch# как файл заплатки.
• указывает количество отбрасываемых директорий для команды patch(1).
• Действие по умолчанию — наложение (или ). Этот флаг запрещает действие по умолчанию и будет требовать чтобы распаковать главный файл с исходными текстами. Эта опция полезна во второй (и последующих) макросах , которые требуют номера отличного от номера в первом макросе.
• Вы также можете выполнять вместо выполнения команды:

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

6.5 Раздел Build

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

6.6 Раздел Install

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

Вы можете считать свою текущую директорию как корневую директорию для исходных текстов пакета.

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

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

• макрос для выполнения предустановочного скрипта.
• макрос для выполнения послеустановочного скрипта.

• макрос для выполнения скрипта перед удалением пакета.
• макрос для скрипта выполняемого после удаления пакета.

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

6.8 Раздел Files

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

Есть несколько доступных макросов для выполнения специальных действий. Они перечислены и описаны здесь:

• используется для обозначения документации в исходных текстах пакета, которую вы хотите установить при установке. Документы будут установлены в директорию . Вы можете перечислить много документов в командной строке этого макроса или вы можете перечислить все отдельно, используя этот макрос для каждого документа.
• используется для обозначения конфигурационных файлов в пакете. Этот список включает файлы подобные sendmail.cf, passwd, и т.п. Если вы позже удаляете пакет содержащий конфигурационные файлы, все неизмененные файлы будут удалены и все измененные будут переименованы со старыми названиями с добавлением к имени файла. Вы можете перечислять много файлов в этом макросе.
• обозначает единичную директорию в списке файлов включенную как директория которой владеет пакет. По умолчанию, если вы укажете имя директории БЕЗ макроса , то ВСЕ в этой директории будет включено в список файлов и позже установлено как часть пакета.
• позволит вам перечислить ваши файлы в некотором файле внутри директории построения исходных текстов. Это просто великолепно в случае когда у вас пакет, который может построить свой собственный список файлов. Затем вы просто включаете этот список файлов здесь и вы не должны специально перечислять файлы.

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

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

Дерево директорий исходных текстов

Первая вещь которая вам необходима — это правильно настроенное дерево построения. Это настраивается используя файл . Большинство людей просто используют директорию .

Вам надо создать следующие директории чтобы создать дерево построения:

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

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

Первая вещь которую вы вероятно захотите сделать — это построить исходные тексты без использования RPM. Чтобы сделать это распакуйте исходные тексты и измените имя директории на $NAME.orig. Затем еще раз распакуйте исходные тексты. Используйте эти исходные тексты для построения. Перейдите в директорию исходных текстов и следуйте инструкциям по их построению. Если вы что-то редактировали вам необходимо сделать заплатку.

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

Это создаст для вас заплатку, которую вы сможете использовать в вашем spec-файле. Заметим что «linux», который вы видите в имени заплатки это просто идентификатор. Вы можете захотеть использовать что-нибудь более описательное как «config» или «bugs» для описания почему вы сделали эту заплатку. Также хорошая идея посмотреть в файл заплатки, который вы создали, до его использования чтобы убедиться что бинарные файлы случайно не включены.

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

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

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

Построение пакета с помощью RPM

Когда вы имеете spec-файл, вы готовы попытаться и построить ваш пакет. Наиболее полезный способ сделать это — использовать команду похожую на следующую:

Также существуют другие опции полезные с переключателем :

• обозначает просто запуск раздела spec-файла.
• это проверка списка, который делает некоторые проверки раздела .
• выполняет раздел prep и компиляцию. Это полезно в случае, когда вы не уверены будут ли ваши исходные тексты построены. Это выглядит бесполезно, потому-что вы можете захотеть просто самому поиграть с исходными текстами до их построения и затем начать использовать RPM, но когда вы привыкнете использовать RPM вы найдете случаи когда этот ключ используется.
• выполняет prep, компиляцию и установку.
• выполняет prep, компиляцию, установку, и построения двоичного пакета.
• строит все (и двоичный пакет и пакет с исходными текстами).

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

• будет пропускать действия до указанной стадии (может использоваться с ключами c и i).
• удаляет дерево построения когда все сделано.
• будет сохранять все временные файлы и скрипты которые созданы в /tmp. Вы можете в действительности посмотреть какие файлы созданы в директории /tmp используя опцию .
• не выполняет никакую реальную стадию, но делает keep-temp.

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

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

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

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

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

6.12 Что теперь?

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

---

NextPreviousContents