Программа RPM предназначена для произведения всех видов операций с программным обеспечением, в том числе и для создания пакетов для установки (RPM-пакетов).
Прежде, чем описать много сухих фактов, взятых из документации, рассмотрим простой пример создания небольшого RPM-пакета. Я создал этот пакет для своей программки, которая контролирует состояние указанного последовательного порта.
Будем считать, что программа уже откомпилирована
и все файлы, необходимые для ее работы, уже подготовлены. Нам нужны следующие
файлы:
port - откомпилированный бинарный файл
README - файл
port.1 -
файл для справочной системы man
Все эти файлы я поместил в каталог /root/port. Конечно, это не совсем корректно, но об этом будет сказано немного позже.
Для создания пакета нам нужно создать файл спецификаций. В файле спецификаций указывается вся информация о создаваемом пакете: название, версия, файлы программ, файлы документации, действия, выполняемые при установке пакета и при его удалении.
Вот мой файл спецификаций для программы port
Листинг 1.
# /root/port/port.spec # Файл спецификаций для программы port # Общее описание программы Summary: Program to control your serial device # Название пакета Name: port # Его версия Version: 1.0 # Релиз Release: 99 # Группа программного обеспечения. Группы (или категории) используются многими # программами для манипуляции пакетами, например gnorpm, которая строит дерево # категорий установленного программного обеспечения Group: Monitoring # Если хотите, можете указать свое имя, но обычно указывается GPL License: GPL # Можно также указать и copyleft # Copyright: GPL # Наш пакет ни с чем не конфликтует # Conflicts: # Менеджер сам заполнит это поле при необходимости # (только для создания двоичных пакетов!) # Require: # Информация о создателе пакета Packager: Denis Kolisnichenko URL: http://dkws.narod.ru # Тэги Summary, Name, Version, Release, Group, License являются обязательными # Из вышеуказанной информации видно, что будет создан пакет: # port-1.0-99.i686.rpm # Архитектура у вас может отличаться # Полное описание пакета %description Программа port предназначена для мониторинга состояния последовательного порта. При получении сигнала (1) на какой-нибудь контакт указанного порта, port отправляет сообщение запустившему ее пользователю на указанный email # Файлы, которые будут помещены в пакет %files %doc /root/port/README /root/port/port /root/port/port.1
Для построения пакета нужно ввести команду:
# rpm -bb /root/port/port.spec
Если вы не допустили никаких ошибок при создании файла спецификаций, на экране вы увидите примерно такое сообщение:
Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.33439 Processing files: port-1.0-99 Finding Provides: (using /usr/lib/rpm/find-provides)... Finding Requires: (using /usr/lib/rpm/find-requires)... Requires: ld-linux.so.2 libc.so.6 libc.so.6(GLIBC_2.0) Записан: /usr/src/RPM/RPMS/i686/port-1.0-99.i686.rpm
При этом будет создан пакет port-1.0-99.i686.rpm. Этот пакет будет помещен в каталог /usr/src/RPM/RPMS/i686
Проведем небольшой эксперимент. Запустите Midhight Commander (mc), перейдите в каталог /usr/src/RPM/RPMS/i686/ и "войдите" в пакет port-1.0-99.i686.rpm как в обычный каталог. В нем будет "подкаталог" INFO, в котором и содержится вся информация о пакете.
Что ж, мы успешно разобрались с построением простого пакета, но для создания реальных пакетов установки наших знаний все еще не хватает. Теперь настала очередь той сухой теории, о которой я упомянул в начале статьи.
Традиционно, процедура создания RPM-пакетов состоит из следующих этапов:
- Извлечения исходных текстов программы из архива
- Компилирование программы из исходных текстов
- Создание RPM-пакета
Первые два этапа можно пропустить, что мы и сделали при создании нашего пакета. Это можно сделать только в случае, если программа уже откомпилирована из исходных текстов.
Программа RPM использует файл конфигурации rpmrc. Поиск этого файла происходит в каталогах /usr/lib/rpm, /etc, $HOME. Просмотреть этот файл можно с помощью команды:
# rpm --showrc
Запись topdir файла конфигурации rpmrc содержит название каталога, в котором находится дерево подкаталогов, которое используется менеджером RPM для постороения пакетов. Введите команду:
# rpm --showrc | grep topdir -14: _builddir %{_topdir}/BUILD -14: _rpmdir %{_topdir}/RPMS -14: _sourcedir %{_topdir}/SOURCES -14: _specdir %{_topdir}/SPECS -14: _srcrpmdir %{_topdir}/SRPMS -14: _topdir %{_usrsrc}/RPM
У меня эти подкаталоги находятся в каталоге /usr/src/RPM. Как вы видите, в этом каталоге находятся подкаталоги BUILD, RPMS, SOURCES, SPECS, SRPMS.
В каталоге BUILD создается RPM-пакет. В каталоге SOURCES находятся сжатые исходные тексты программы. В каталог RPMS помещаются созданные пакеты. Точнее, они помещаются в один из его подкаталогов, в какой именно - это зависит от архитектуры. В каталог SRPMS помещаются пакеты, содержащие исходные тексты программы.
В каталоге SPECS находятся файлы спецификаций. Обычно файл спецификации называется название_программы-версия-релиз.spec.
Например, если у вас есть исходный текст программы в архиве, из которого вы хотите создать пакет RPM, скопируйте его в каталог SOURCES
# cp source_code-1.0.tar.gz /usr/src/RPM/SOURCES
По умолчанию менеджер RPM работает с пакетами, расположенным в каталоге с именем, совпадающем с названием пакета и его версией. Для нашего пакета port это будет каталог port-1.0-99. Менеджер пакетов будет компилировать наш пакет в каталоге /usr/src/RPM/port-1.0-99
Думаю, уже достаточно информации о каталогах RPM. Теперь перейдем к файлу спецификаций. Файл спецификаций состоит из четырех сегментов: заголовка, подготовительного, файлового, установочного.
В заголовке указывается общая информация о пакете. В листинге 1 к сегменту заголовка относятся тэги Summary, Name, Version, Release, Group и Licese. На них мы останавливаться не будем, так как их назначение понятно из листинга 1.
Есть еще очень полезный тэг: BuildRoot. Он изменяет расположение дерева BUILD. Значением по умолчанию является /usr/src/RPM или другой каталог, задаваемый переменной окружения $RPM_BUILD_ROOT. В целях экономии дискового пространства полезно после установки удалить дерево %RPM_BUILD_ROOT. Но дерево по умолчанию может содержать другие файлы, относящиеся к другим пакетам. Поэтому сначала с помощью тэга BuildRoot нужно задать какой-нибудь временный каталог, а после установки удалить его.
В каждом сегменте находятся макрокоманды. С некоторыми мы уже знакомы - это %description, %files, %doc, %install. В таблице 1 приведено полное описание макрокоманд.
Таблица 1.
| Макрокоманда | Описание |
| %description | Полное описание пакета |
| %prep | Подготовка архива. Здесь задаются команды для извлечения исходного текста программы и его распаковки, дополнительная подготовка исходного текста. После макрокоманды %prep задаются обычные команды shell. |
| %setup | Макрокоманда извлечения файлов из архивов. Опция -n позволяет указать каталог, в котором будет создаваться новый пакет. Обычно распаковывается архив, расположенный в каталоге SOURCES в каталог BUILD |
| %build | Макрокоманда компилирования. Обычно здесь запускается программа make с необходимыми параметрами |
| %files | Задает список файлов, входящих в состав пакета. При указании имен файлов должен быть указан полный, а не относительный путь. Для указания полного пути можно использовать переменную окружения $RPM_BUILD_ROOT. Необходимые файлы уже должны быть помещены в каталог BUILD. Этого можно достичь с помощью макрокоманды %setup или с помощью %pre (см. ниже) |
| %config список | Задает список файлов, которые будут помещены в каталог /etc |
| %doc список | Задает список файлов, которые будут помещены в каталог /usr/doc/--. |
| %install | Этап установки программного обеспечения. Здесь нужно записать команды, которые будут устанавливать файлы, входящие в состав пакета. Удобнее использовать команду install, которую я использовал в листинге 1 |
| %pre | Действия, которые будут выполнены до инсталляции пакета |
| %post | Действия, которые будут выполнены после инсталляции пакета |
| %preun | Действия, которые будут выполнены перед удалением пакета |
| %postun | Действия, которые будут выполнены после удаления пакета |
| %clean | Удаление дерева BUILD. Используется вместо опции --clean программы rpm. Обычно содержит одну команду: rm -rf $RPM_BUILD_ROOT |
Нужно сделать небольшое замечание относительно макрокоманд %config и %doc. В этом случае список задается не так, как в макрокоманде %files. Если после макрокоманды %files можно было просто указать по одному файлу в каждой строке, то в макрокоманде %doc каждому файлу (или каждому списку) должна предшествовать команда %doc. Например,
%doc README TODO Changes %doc Install а не %doc README TODO Changes Install
Еще раз отмечу, что наличие всех макрокоманд в файле спецификаций не является обязательным.
При создании пакета мы использовали опцию -bb программы rpm. При указании этой опции создается только двоичный RPM-пакет, если вы хотите создать также пакет, содержащий исходный текст программы, используйте опцию -ba. Созданный пакет помещается в каталог SRPMS и будет иметь имя port-1.0-99.src.rpm. То есть вместо названия архитектуры будет указано, что данный пакет содержит исходный текст программы. Для создания такого пакета в каталоге SOURCES должны находиться исходные тексты программы.
Для полноты картины осталось рассмотреть опции менеджера rpm, которые используются для создания пакетов.
Таблица 2.
| -ba | Создаются два пакета: двоичный и содержащий исходный текст. При этом не пропускается ни один этап установки, указанный в файле спецификаций |
| -bb | Создается только двоичный пакет. Не пропускается ни один этап установки, указанный в файле спецификаций |
| -bc | Выполняются этапы %pre и %build. При этом пакет распаковывается и компилируется |
| -bi | Выполняются этапы %pre, %build, %install |
| -bl | Выполняется проверка списка файлов, указанных в макрокоманде %files |
| -bp | Выполняется только этап %pre, то есть распаковывается архив |
| --recompile package.src.rpm | Указанный пакет, содержащий исходные тексты, сначала устанавливается, а потом компилируется |
| --rebuild package.src.rpm | Устанавливает и компилируется пакет исходных текстов, а затем создается новый двоичный пакет |
| --test | Проверка файла спецификаций |
| --clean | Удаление дерева каталогов BUILD после создания пакета |
| --showrc | Выводит файл конфигурации |
Есть две машины, идентичная версия / арка SLES.
На компьютере #A установлено программное обеспечение «foo», которое мы можем увидеть с помощью rpm -qa .
На машине #B необходимо установить программное обеспечение «foo».
foo.rpm недоступен из любого источника, из Интернета и т. Д.
Вопрос
Так как пакет foo.rpm был установлен на машине #A, можем ли мы создать файл foo.rpm на нем из уже установленных файлов?
По-моему, есть и сценарии pre / post в rpm. Таким образом, можно установить foo.rpm (с зависимостями? ).
2 Solutions collect form web for “Как создать пакет RPM из установленных файлов?”
Это возможно, но очень сложно сделать это, чтобы все было сделано правильно. Если вы в отчаянии, вы можете создать новый файл RPM .spec и создать «фальшивый» исходный RPM-файл (SRPM), который затем можно использовать для создания результирующего файла RPM с помощью rpmbuild --rebuild .
Я бы продолжил поиск фактического RPM. Вы не указываете, что в вашем вопросе, но мой опыт заключается в том, что вы можете найти что-нибудь в Интернете, если знаете, как его искать. Я нашел древние версии RPM для дистрибутивов Red Hat, которые не использовались в течение более 10 лет, поэтому мне было бы трудно поверить, что в этом RPM нет остатка.
Также вы можете часто возвращаться к источнику приложения, который содержится в RPM, и использовать его для восстановления RPM. Часто исходные приложения будут содержать необходимый файл.spec который используется для восстановления RPM.
Наконец, вы можете получить источник и файл.spec из службы построения, например, для дистрибутивов на основе Koji для Red Hat. SuSE поддерживает аналогичные услуги сборки, поэтому вы можете искать их, чтобы получить старые артефакты сборки.
Взятие двоичных файлов как
Вы можете использовать этот метод, чтобы поднять фактические исполняемые файлы из одной системы и разгрузить их для развертывания в другой системе.
машина A
$ rpm -ql
машина B
$ tar -zxvf /path/to/your/program.tgz
Версия RPM от SLES
Согласно одному из сообщений в этом потоке: Re: Как создать RPM fron установленные пакеты rpm на SLES предполагается иметь переключатель --repackage . Этого не существует в версии Red Hat (в Fedora или CentOS). Но, согласно сообщению, вы можете использовать его так:
$ rpm -e --repackage
После этого вы найдете здесь свой RPM:
/var/spool/repackage
Использование rpmerizor
Rpmerizor является сторонним инструментом / скриптом, который вы можете установить, который будет повторно упаковывать исходные файлы в соответствующий RPM. Использование этого скрипта доступно здесь, под названием: справочная страница rpmerizor .
выдержка
Rpmerizor – это скрипт, который позволяет вам создавать RPM-пакет из установленных файлов. Вам просто нужно указать файлы в командной строке и ответить на несколько интерактивных вопросов, чтобы заполнить метаданные rpm (имя пакета, версия …). Вы также можете использовать его в пакетном режиме с параметрами командной строки для метаданных.
Использование rpmrebuild
Чтобы не путать с инструментом сборки rpmbuild , rpmrebuild – это еще один сторонний скрипт, который вы можете использовать для повторной упаковки уже установленного RPM.
выдержка
rpmrebuild – это инструмент для создания RPM-файла из пакета, который уже был установлен при базовом использовании, использование rpmrebuild не требует каких-либо знаний о создании rpm. (На debian эквивалентный продукт – dpkg-repack).
пример
Предположим, мы хотим переупаковать openssh-сервер.
$ rpm -aq | grep openssh-server openssh-server-6.2p2-8.fc19.x86_64
Теперь пакет:
$ rpmrebuild openssh-server-6.2p2-8.fc19.x86_64 /usr/lib/rpmrebuild/rpmrebuild.sh: WARNING: some files have been modified: ..?...... c /etc/ssh/sshd_config ..?...... c /etc/sysconfig/sshd Do you want to continue ? (y/N) y Do you want to change release number ? (y/N) n result: /root/rpmbuild/RPMS/x86_64/openssh-server-6.2p2-8.fc19.x86_64.rpm
- Re : Как создать RPM-установленные установленные пакеты
Как правило, нет.
С небольшим rpm -qi и rpm -q --changelog дают представление о том, откуда появился пакет.
Если он был построен на системе, на которой он работает, вы все равно можете использовать файл spec, используемый для создания фактических оборотов, если не оба.
rpm -q --list
rpm -q --scripts
И любые зависимости, которые необходимо установить, можно найти с помощью rpm -q --requires
Иногда встречаются полезные программы, доступные только в виде исходных кодов (и/или в виде установочных пакетов для других ОС), но есть необходимость их установки на несколько компьютеров. Чтобы не выполнять компиляцию на каждом компьютере отдельно, можно на одном подготовить установочный пакет и установить его штатными средствами на других компьютерах.
Ниже приведён пример создания RPM пакета для Fedora 21 (для других версий Fedora процедура не отличается) из исходных текстов очень приятной и полезной программы Boomaga версии 0.7.0.
Готовим инструменты сборки RPM
Для начала я попытался установить необходимые инструменты (как мне посоветовала ):sudo dnf install @development-tools но эта команда не выполнилась, ссылаясь на отсутствие группы development-tools. Тогда я установил всё другой командой, которую мне подсказала :
sudo dnf groupinstall "Development Tools" и ещё две команды из обеих вышеуказанных статей:
sudo dnf install rpmdevtools sudo dnf install fedora-packager Затем надо сгенерировать рабочее пространство для сборки RPM:
rpmdev-setuptree В результате этой команды создадутся необходимые каталоги в домашнем каталоге текущего пользователя (показываю содержимое нового каталога rpmbuild ):
$ ls ~/rpmbuild/ BUILD BUILDROOT RPMS SOURCES SPECS SRPMS В каталог SOURCES сразу перемещаю архив исходников (boomaga-0.7.0.tar.gz), как он есть. Кстати, тут есть небольшой подвох от github, - ссылка на закачку не даётся напрямую, а генерируется только после клика по ней. Из-за этого не получилось указать прямую ссылку на архив в интернете в SPEC файле, о котором пойдёт речь ниже.
Готовим SPEC файл
Для упаковки исходных текстов программы в RPM пакет нужен специальный файл с описанием необходимых действий. Сгенерируем шаблон:rpmdev-newspec boomaga В результате этой команды будет создан файл boomaga.spec в каталоге ~/rpmbuild/SPEC. Тут важно название SPEC файла. Оно должно совпадать с названием программы (т.е. без номера версии). После автоматической генерации SPEC файла переходим к его редактированию. В моём случае это получилось так:
Name: boomaga Version: 0.7.0 Release: 1%{?dist} Summary: Boomaga is a virtual printer for viewing a document before printing License: GPLv2 and LGPLv2+ URL: http://boomaga.github.io Source0: %{name}-%{version}.tar.gz BuildRequires: cmake,cups-devel,poppler-devel,poppler-cpp-devel,qt5-qtbase-devel,qt5-qttools-devel,snappy-devel Requires: cups %description Boomaga (BOOklet MAnager) is a virtual printer for viewing a document before printing it out using the physical printer. The program is very simple to work with. Running any program, click “print” and select “Boomaga” to see in several seconds (CUPS takes some time to respond) the Boomaga window open. If you print out one more document, it gets added to the previous one, and you can also print them out as one. %prep %setup -q %build mkdir build cd build cmake .. %make_install %files %defattr(0755,root,root,-) /usr/lib/cups/backend/boomaga /usr/lib/cups/filter/boomaga_pstopdf /usr/local/bin/boomaga /usr/local/lib/boomaga/boomagabackend /usr/local/lib/boomaga/boomagamerger /usr/local/share/applications/boomaga.desktop /usr/local/share/boomaga/translations/boomaga_cs.qm /usr/local/share/boomaga/translations/boomaga_de.qm /usr/local/share/boomaga/translations/boomaga_el.qm /usr/local/share/boomaga/translations/boomaga_fr.qm /usr/local/share/boomaga/translations/boomaga_it.qm /usr/local/share/boomaga/translations/boomaga_lt.qm /usr/local/share/boomaga/translations/boomaga_pl_PL.qm /usr/local/share/boomaga/translations/boomaga_ru.qm /usr/local/share/boomaga/translations/[email protected] /usr/local/share/dbus-1/services/org.boomaga.service /usr/local/share/icons/hicolor/128x128/apps/boomaga.png /usr/local/share/icons/hicolor/16x16/apps/boomaga.png /usr/local/share/icons/hicolor/32x32/apps/boomaga.png /usr/local/share/icons/hicolor/64x64/apps/boomaga.png /usr/local/share/mime/packages/boomaga.xml /usr/share/ppd/boomaga/boomaga.ppd %attr(0644,root,root) %doc /usr/local/share/man/man1/boomaga.1.gz %changelog * Mon Jun 22 2015 Oleg - Всё, что идёт после знака процента является макросом (например, %build) или предопределённым значением (например, %{name}). Как сказано в документации Fedora , перечень и описание всех макросов можно найти в каталогах:
- /etc/rpm/*
- /usr/lib/rpm
- /usr/lib/rpm/macros
rpm --showrc Прокомментирую указанные значения.
Параметр Name должен совпадать с именем SPEC файла и названием программы (указывается без номера версии).
Параметр Source0 должен по-хорошему указывать на архив в интернете, который имеет такое же название, как и файл в каталоге ~/rpmbuild/SOURCES, но т.к. ссылки на boomaga-0.7.0.tar.gz в интернете я не нашёл, то указал локальную ссылку. Без пути. Только название файла и с использованием переменных (берутся из указанных выше одноимённых параметров).
Перед тем, как пытаться собрать RPM пакет, я пробовал скомпилировать программу обычным образом. Для этого понадобилось установить инструмент cmake и зависимости данной программы: cups-devel, poppler-devel, poppler-cpp-devel, qt5-qtbase-devel, qt5-qttools-devel, snappy-devel. Все эти пакеты я указал в параметре BuildRequires .
Т.к. boomaga может работать в роли виртуального принтера как прослойка между CUPS, то я указал cups в параметре Requires .
Далее идут макросы, которые будут выполняться при сборке RPM пакета.
После макроса %description делаем переход на новую строку и вставляем описание из родного сайта проекта.
Макрос %setup -q распаковывает исходные коды в каталог ~/rpmbuild/BUILD/%{name}-%{version}, т.е. в нашем случае - ~/rpmbuild/BUILD/boomaga-0.7.0
Далее начинается самое ответственное. Нужно описать всё для автоматической компиляции проекта. Я поступил так. Открыл официальную инструкцию по установке данного приложения и переделал под текущую ситуацию. Инструкция по установке оказалась весьма лаконичной и понятной:
mkdir ~/boomaga/build cd ~/boomaga/build cmake .. make && sudo make install В форме макросов в SPEC файле эти инструкции выразились так:
%build mkdir build cd build cmake .. %make_install Первый макрос %build отвечает за сборку исходников. В этой фазе создаём каталог build в текущем каталоге (т.е. в ~/rpmbuild/BUILD/boomaga-0.7.0) и перемещаемся в него. Потом запуск cmake для генерации Makefile. Т.е. всё то, что написано в инструкции по обычной установке данной программы.
Затем макрос %make_install собирёт всё каталоге в ~/rpmbuild/BUILDROOT/boomaga-0.7.0-1.fc21.R.x86_64 так, как если бы шла нормальная установка. Т.е. там создаётся каталог usr со всеми задействованными подкаталогами.
Операции макросов %files (тут нужно указать список всех файлов, входящих в RPM пакет) и %doc (вся документация) заполнил в соответствии с подсказками после первых неудачных запусков, - при сборке пакета выводилось сообщение:
Processing files: boomaga-debuginfo-0.7.0-1.fc21.R.x86_64 Проверка на неупакованный(е) файл(ы): /usr/lib/rpm/check-files /home/oleg/rpmbuild/BUILDROOT/boomaga-0.7.0-1.fc21.R.x86_64 ошибка: Обнаружен(ы) установленный(е) (но не упакованный(е)) файл(ы): /usr/lib/cups/backend/boomaga /usr/lib/cups/filter/boomaga_pstopdf /usr/local/bin/boomaga /usr/local/lib/boomaga/boomagabackend /usr/local/lib/boomaga/boomagamerger /usr/local/share/applications/boomaga.desktop /usr/local/share/boomaga/translations/boomaga_cs.qm /usr/local/share/boomaga/translations/boomaga_de.qm /usr/local/share/boomaga/translations/boomaga_el.qm /usr/local/share/boomaga/translations/boomaga_fr.qm /usr/local/share/boomaga/translations/boomaga_it.qm /usr/local/share/boomaga/translations/boomaga_lt.qm /usr/local/share/boomaga/translations/boomaga_pl_PL.qm /usr/local/share/boomaga/translations/boomaga_ru.qm /usr/local/share/boomaga/translations/[email protected] /usr/local/share/dbus-1/services/org.boomaga.service /usr/local/share/icons/hicolor/128x128/apps/boomaga.png /usr/local/share/icons/hicolor/16x16/apps/boomaga.png /usr/local/share/icons/hicolor/32x32/apps/boomaga.png /usr/local/share/icons/hicolor/64x64/apps/boomaga.png /usr/local/share/man/man1/boomaga.1.gz /usr/local/share/mime/packages/boomaga.xml /usr/share/ppd/boomaga/boomaga.ppd Ошибки сборки пакетов: Обнаружен(ы) установленный(е) (но не упакованный(е)) файл(ы): /usr/lib/cups/backend/boomaga /usr/lib/cups/filter/boomaga_pstopdf /usr/local/bin/boomaga /usr/local/lib/boomaga/boomagabackend /usr/local/lib/boomaga/boomagamerger /usr/local/share/applications/boomaga.desktop /usr/local/share/boomaga/translations/boomaga_cs.qm /usr/local/share/boomaga/translations/boomaga_de.qm /usr/local/share/boomaga/translations/boomaga_el.qm /usr/local/share/boomaga/translations/boomaga_fr.qm /usr/local/share/boomaga/translations/boomaga_it.qm /usr/local/share/boomaga/translations/boomaga_lt.qm /usr/local/share/boomaga/translations/boomaga_pl_PL.qm /usr/local/share/boomaga/translations/boomaga_ru.qm /usr/local/share/boomaga/translations/[email protected] /usr/local/share/dbus-1/services/org.boomaga.service /usr/local/share/icons/hicolor/128x128/apps/boomaga.png /usr/local/share/icons/hicolor/16x16/apps/boomaga.png /usr/local/share/icons/hicolor/32x32/apps/boomaga.png /usr/local/share/icons/hicolor/64x64/apps/boomaga.png /usr/local/share/man/man1/boomaga.1.gz /usr/local/share/mime/packages/boomaga.xml /usr/share/ppd/boomaga/boomaga.ppd В результате успешной сборки формируются RPM пакеты:
~/rpmbuild/RPMS/x86_64/boomaga-0.7.0-1.fc21.R.x86_64.rpm
~/rpmbuild/RPMS/x86_64/boomaga-debuginfo-0.7.0-1.fc21.R.x86_64.rpm
~/rpmbuild/SRPMS/boomaga-0.7.0-1.fc21.R.src.rpm
А вот, собственно, как запускать сборку:
rpmbuild --target=x86_64 -ba ~/rpmbuild/SPECS/boomaga.spec Команда отрабатывает за пару минут. В это время в консоли пролетают красивые разноцветные строчки.
Позже, когда дистрибутив Fedora обновится до следующей версии, можно будет попробовать перепаковать пакет boomaga-0.7.0-1.fc21.R.src.rpm такой командой:
rpmbuild --rebuild boomaga-0.7.0-1.fc21.R.src.rpm
Теоретически это позволит сократить время сборки RPM пакета.
Для проверки SPEC файла и формируемого пакета можно перейти в каталог ~/rpmbuild/SPEC и воспользоваться командой:
rpmlint boomaga.spec ../SRPMS/boomaga* ../RPMS/*/boomaga*
В результате будут показаны различные предупреждения и ошибки. В моём случае есть ошибки расположения файлов. Но для личного пользования подойдёт и так. Хотя с такими ошибками в официальные репозитории не пропустят.
Посмотреть описание ошибки можно, указав её название после ключа -I в следующей команде:
rpmlint -I hardcoded-library-path
Полезные ссылки
Различных параметров и макросов существует довольно много. В официальной документации Fedora есть исчерпывающие полезные и обширные материалы "How to create an RPM package " и "Packaging:Guidelines ". Также есть пример с пояснениями SPEC файла в материале "Annotated spec file ".Делаем RPM лучше
Чтобы полученный RPM пакет не только выполнял свою функцию, но и делал это правильно, нужно избавиться от всех ошибок, на которые указывает rpmlint.
Основная ошибка состоит в том, что полученные файлы в системе устанавливаются не туда, куда положено. Во-первых, всё должно соответствовать стандарту Filesystem Hierarchy Standard , который недавно обновился . Во-вторых RPM пакет для Fedora должен соответствовать правилам этого дистрибутива.
Нужно избавиться от жёстко прописанных путей в секции %files. Для этого применяются макросы. В моём случае исходный код программы в нескольких местах имел жёстко прописанный путь в подкаталог lib, а для архитектуры x86_64 нужно было указывать lib64. Поэтому потребовалось немного подкорректировать исходный код программы .
В результате общения с разработчиками программы на github.com , SPEC файл пополнился также автоматическим прописыванием принтера в системе. Плюс программа Boomaga успела обновиться до версии 0.7.1. Результирующий SPEC файл:
Name: boomaga
Version: 0.7.1
Release: 1%{?dist}
Summary: A virtual printer for viewing a document before printing
License: GPLv2 and LGPLv2+
URL: http://boomaga.github.io
Source0: %{name}-%{version}.tar.gz
BuildRequires: cmake,cups-devel,poppler-devel,poppler-cpp-devel,qt5-qtbase-devel,qt5-qttools-devel,snappy-devel
Requires: cups,snappy
%description
Boomaga (BOOklet MAnager) is a virtual printer for viewing a document
before printing it out using the physical printer.
The program is very simple to work with.
Running any program, click “print” and select “Boomaga” to see in several
seconds (CUPS takes some time to respond) the Boomaga window open.
If you print out one more document,
it gets added to the previous one, and you can also print them out as one,
and you can also print them out as one.
Regardless of whether your printer supports duplex printing or not,
you would be able to easily print on both sides of the sheet.
If your printer does not support duplex printing,
point this out in the settings, and Booklet would ask you to turn
over the pages half way through printing your document.
The program can also help you get your documents prepared a bit
before printing. At this stage Boomaga makes it possible to:
* Paste several documents together.
* Print several pages on one sheet.
* 1, 2, 4, 8 pages per sheet
* Booklet. Folding the sheets in two, you’ll get a book.
%prep
%setup -q
%build
%ifarch x86_64
%cmake -DLIB_SUFFIX=64 -DCUPS_BACKEND_DIR=%{_libdir}/cups/backend -DCUPS_FILTER_DIR=%{_libdir}/cups/filter .
%else
%cmake -DCUPS_BACKEND_DIR=%{_libdir}/cups/backend -DCUPS_FILTER_DIR=%{_libdir}/cups/filter .
%endif
make %{?_smp_mflags}
%install
make install DESTDIR=%{buildroot}
%__mkdir -p %{buildroot}%{_datadir}/%{name}/scripts
%__install -m 755 scripts/installPrinter.sh %{buildroot}%{_datadir}/%{name}/scripts/
chmod +x %{buildroot}%{_datadir}/%{name}/scripts/installPrinter.sh
# Add translation lang tags
(cd %{buildroot} && find . -name "*.qm") | %__sed -e "s|^.||" | sed -e \
"s:\(.*/translations/boomaga_\)\(\+\)\(.*qm$\):%lang(\2) \1\2\3:"\
>> %{name}.lang
%pre
# Start cups if is stopped
if [ "$(systemctl is-active cups.service)" != "active" ]; then
systemctl start cups
sleep 2
fi
%post
# Install the printer to cups backends
if [ $1 = 1 ]; then
sh %{_datadir}/%{name}/scripts/installPrinter.sh
fi
%preun
# Uninstall the printer
lpadmin -x "Boomaga"
%files
%defattr(755,root,root,-)
%{_libdir}/cups/backend/%{name}
%defattr(-,root,root,-)
%{_libdir}/cups/filter/boomaga_pstopdf
%{_bindir}/%{name}
%{_libdir}/%{name}/boomagabackend
%{_libdir}/%{name}/boomagamerger
%{_datadir}/applications/boomaga.desktop
%{_datadir}/%{name}/translations/*
%{_datadir}/dbus-1/services/org.boomaga.service
%{_datadir}/icons/hicolor/*
%{_datadir}/mime/packages/boomaga.xml
%{_datadir}/ppd/%{name}/boomaga.ppd
%{_datadir}/%{name}/scripts/installPrinter.sh
%doc COPYING GPL LGPL README.md
%{_mandir}/man1/boomaga.1.gz
%changelog
* Tue Jun 30 2015 Oleg Ekhlakov
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".
Source0 : Ссылка на архив с исходным кодом. Если указана полная ссылка, то одноименный пакет должен быть в папке SOURCES. Если источников исходного кода несколько, то используем Source1 , Source2 и т.д.
Patch0 : Название первого патча для программы, имя файла должно заканчиваться на.patch и лежать в директории ~/rpmbuild/SOURCES. Патчей может быть несколько.
BuildArch : Архитектура программы под определенные процессоры. Для универсальных пакетов "noarch".
BuildRoot : Место, выделенное для компиляции и установки исходников приложения во время выполнения процесса "%install". По стандарту Fedora, будет создана специальная директория в /var/tmp. Более новые версии 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
: Изменения в программе.
Статья подготовлена опираясь на официальный источник от
Но часто бывает так, что вам необходимо собрать пакет с необходимыми опциями (включить поддержку mysql, postgresql или cyrus-sasl2 и т.п.), которые отсутствуют в rpm пакете, поставляемом на диске с дистрибутивом. Выходом из этой ситуации является сборка своего собственного пакета.
Для облегчения сборки rpm пакетов существует специально предназначенный для этих целей пакет - rpm-build.
# rpm -qi rpm-build Name: rpm-build Relocations: (not relocatable) Version: 4.3.3 Vendor: CentOS Release: 7_nonptl Build Date: Пнд 21 Фев 2005 20:21:52 Install Date: Сбт 09 Апр 2005 22:14:57 Build Host: guru.build.karan.org Group: Development/Tools Source RPM: rpm-4.3.3-7_nonptl.src.rpm Size: 1576124 License: GPL Signature: DSA/SHA1, Вск 27 Фев 2005 00:36:59, Key ID a53d0bab443e1821 Packager: Karanbir Singh
Как видно из описания этот пакет содержит набор скриптов и программ, предназначенных для сборки пакетов.
Для того, чтобы собрать какой-либо пакет для начала необходимо загрузить т.н. исходники для сборки пакета, как правило, это файлы с расширением src.rpm. Иногда, как в случае с courier-imap, spec файл включается в исходные коды.
Очень удобным для поиска rpm и src.rpm пакетов является сайт www.rpmfind.net . Например, мы нашли необходимый нам пакет - postfix, squid и т.д. Мы сразу можем узнать какие пакеты, необходимы для его сборки. Вот стандартная страница с информацией о пакете для postix и для squid . Также там указывается контрольная сумма для проверки целостности пакета.
После того, как мы получили исходники и проверили их целостность, необходимо установить соответствующий пакет.
# rpm -ivh postfix-2.2.8-1.2.src.rpm 1:postfix ###########################################
После выполнения данной операции исходники postfix и все необходимые пачти, а также скрипты были установлены в /usr/src/redhat/SOURCES/, а spec файл (инструкция для сборки rpm пакета) в /usr/src/redhat/SPECS/.
# ls /usr/src/redhat/SOURCES/ pflogsumm-1.1.0.tar.gz postfix-etc-init.d-postfix postfix-2.1.1-config.patch postfix-hostname-fqdn.patch postfix-2.1.1-obsolete.patch postfix-large-fs.patch postfix-2.1.5-aliases.patch postfix-pam.conf postfix-2.2.5-cyrus.patch postfix-sasl.conf postfix-2.2.8.tar.gz README-Postfix-SASL-RedHat.txt postfix-alternatives.patch # ls /usr/src/redhat/SPECS/ postfix.spec
Это стандартное месторасположение файлов при установке src.rpm. В принципе названия папок говорят сами за себя.
И так, для того, чтобы начать собирать пакет необходимо перейти в папку с spec файлом и выполнить следующую команду
# cd /usr/src/redhat/SPECS/ # rpmbuild -ba --target=i686 postfix.spec Платформы для сборки: i686 Сборка для платформы i686 Выполняется(%prep): /bin/sh -e /var/tmp/rpm-tmp.82019 + umask 022 + cd /usr/src/redhat/BUILD + umask 022 + cd /usr/src/redhat/BUILD + rm -rf postfix-2.2.8 + /bin/gzip -dc /usr/src/redhat/SOURCES/postfix-2.2.8.tar.gz + tar -xf - + STATUS=0 + "[" 0 -ne 0 "]" + cd postfix-2.2.8 ++ /usr/bin/id -u + "[" 0 = 0 "]" + /bin/chown -Rhf root . ++ /usr/bin/id -u + "[" 0 = 0 "]" + /bin/chgrp -Rhf root . + /bin/chmod -Rf a+rX,u+w,g-w,o-w . + echo "Patch #1 (postfix-2.1.1-config.patch):" Patch #1 (postfix-2.1.1-config.patch): + patch -p1 -b --suffix .config -s ... ... ... Записан: /usr/src/redhat/SRPMS/postfix-2.2.8-1.2.src.rpm Записан: /usr/src/redhat/RPMS/i686/postfix-2.2.8-1.2.i686.rpm Записан: /usr/src/redhat/RPMS/i686/postfix-pflogsumm-2.2.8-1.2.i686.rpm Выполняется(%clean): /bin/sh -e /var/tmp/rpm-tmp.73987 + umask 022 + cd /usr/src/redhat/BUILD + cd postfix-2.2.8 + /bin/rm -rf /var/tmp/postfix-buildroot + exit 0
Из последних строчек видно, что готовый rpm пакет называется postfix-2.2.8-1.2.i686.rpm и сохранен в папке /usr/src/redhat/RPMS/i686/, так как при сборке пакета мы указали ключ --target=i686.
Собственно сборка не должна вызвать никаких проблем. Но что если нам необходимо собрать пакет со своими опциями, например, включить поддержку mysql или sasl2 и т.п.? Для этих целей необходимо будет подправить spec файл.
Рассмотрим часть spec файла postfix, надо заметить, что у postfix так сказать нестандартный spec файл.
Например, мы захотели собрать postfix с поддержкой MySQL, для этого в самом начале меняем %define MYSQL 0 на %define MYSQL 1. и снова выполняем команду
# rpmbuild -ba --target=i686 postfix.spec Платформы для сборки: i686 Сборка для платформы i686 ошибка: Неудовлетворенные зависимости сборки: mysql-devel нужен для postfix-2.2.8-1.2.i686
Он нам пишет, что для сборки необходимо установить пакет mysql-devel. Обратите внимание, что версия не указывается, это значит, что можно установить любую версию, которую поддерживает postfix или нужный вам пакет.
Если бы вы собирали из исходных кодов, то вам пришлось бы самому искать, какие пакеты необходимы для сборки данного пакета. В этом и заключается одно из преимуществ сборки из src.rpm по сравнению с tar.gz или tar.bz2.
Устанавливаем соответствующий пакет
# rpm -ivh MySQL-devel-4.1.9-0.i386.rpm Подготовка... ########################################### 1:MySQL-devel ###########################################
И заново запускаем сборку postfix. На этот раз мы видим, что все необходимые пакеты для сборки установлены и теперь необходимо, лишь дождаться окончания сборки.
# rpmbuild -ba --target=i686 postfix.spec Платформы для сборки: i686 Сборка для платформы i686 Выполняется(%prep): /bin/sh -e /var/tmp/rpm-tmp.86320 + umask 022 + cd /usr/src/redhat/BUILD + umask 022 + cd /usr/src/redhat/BUILD + rm -rf postfix-2.2.8 ... ... ... Записан: /usr/src/redhat/SRPMS/postfix-2.2.8-1.2.src.rpm Записан: /usr/src/redhat/RPMS/i686/postfix-2.2.8-1.2.i686.rpm Записан: /usr/src/redhat/RPMS/i686/postfix-pflogsumm-2.2.8-1.2.i686.rpm Выполняется(%clean): /bin/sh -e /var/tmp/rpm-tmp.52381 + umask 022 + cd /usr/src/redhat/BUILD + cd postfix-2.2.8 + /bin/rm -rf /var/tmp/postfix-buildroot + exit 0
Все пакет у нас собран, теперь необходимо установить его и радоваться жизни.
# rpm -ivh /usr/src/redhat/RPMS/i686/postfix-2.2.8-1.2.i686.rpm Подготовка... ########################################### 1:postfix ###########################################
Для лучшего понимания рассмотрим сборку squid, который имеет более стандартную структуру spec файла. Как всегда для начала устанавливаем src.rpm, при этом не забываем проверить размер и контрольную сумму.
# rpm -ivh squid-2.5.STABLE11-2.src.rpm 1:squid ###########################################
Узнать все возможные ключи можно следующим образом.
# cd /usr/src/redhat/SPECS
# rpmbuild --bp squid.spec
# cd ../BUILD/squid-2.5.STABLE11/
# ./configure --help
Usage: configure
Options:
Configuration:
--cache-file=FILE cache test results in FILE
--help print this message
--no-create do not create output files
--quiet, --silent do not print `checking..." messages
--site-file=FILE use FILE as the site file
--version print the version of autoconf that created configure
Directory and file names:
--prefix=PREFIX install architecture-independent files in PREFIX
--exec-prefix=EPREFIX install architecture-dependent files in EPREFIX
--bindir=DIR user executables in DIR
--sbindir=DIR system admin executables in DIR
--libexecdir=DIR program executables in DIR
--datadir=DIR read-only architecture-independent data in DIR
--sysconfdir=DIR read-only single-machine data in DIR
--sharedstatedir=DIR modifiable architecture-independent data in DIR
--localstatedir=DIR modifiable single-machine data in DIR
--libdir=DIR object code libraries in DIR
--includedir=DIR C header files in DIR
--oldincludedir=DIR C header files for non-gcc in DIR
--infodir=DIR info documentation in DIR
--mandir=DIR man documentation in DIR
--srcdir=DIR find the sources in DIR
--program-prefix=PREFIX prepend PREFIX to installed program names
--program-suffix=SUFFIX append SUFFIX to installed program names
--program-transform-name=PROGRAM
run sed PROGRAM on installed program names
Host type:
--build=BUILD configure for building on BUILD
--host=HOST configure for HOST
--target=TARGET configure for TARGET
Features and packages:
--disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no)
--enable-FEATURE[=ARG] include FEATURE
--with-PACKAGE[=ARG] use PACKAGE
--without-PACKAGE do not use PACKAGE (same as --with-PACKAGE=no)
--x-includes=DIR X include files are in DIR
--x-libraries=DIR X library files are in DIR
--enable and --with options recognized:
--disable-dependency-tracking Speeds up one-time builds
--enable-dependency-tracking Do not reject slow dependency extractors
--enable-maintainer-mode enable make rules and dependencies not useful
(and sometimes confusing) to the casual installer
--enable-dlmalloc[=LIB] Compile & use the malloc package by Doug Lea
--enable-gnuregex Compile GNUregex. Unless you have reason to use this
option, you should not enable it. This library file
is usually only required on Windows and very old
Unix boxes which do not have their own regex library
built in.
--enable-xmalloc-statistics
Show malloc statistics in status page
--enable-carp Enable CARP support
--enable-async-io[=N_THREADS]
Shorthand for
--with-aufs-threads=N_THREADS
--with-pthreads
--enable-storeio=ufs,aufs
--with-aufs-threads=N_THREADS
Tune the number of worker threads for the aufs object
store.
--with-pthreads Use POSIX Threads
--with-aio Use POSIX AIO
--with-dl Use dynamic linking
--enable-storeio="list of modules"
Build support for the list of store I/O modules.
The default is only to build the ufs module.
See src/fs for a list of available modules, or
Programmers Guide section
for details on how to build your custom store module
--enable-heap-replacement
Backwards compatibility option. Please use the
new --enable-removal-policies directive instead.
--enable-removal-policies="list of policies"
Build support for the list of removal policies.
The default is only to build the lru module.
See src/repl for a list of available modules, or
Programmers Guide section 9.9 for details on how
to build your custom policy
--enable-icmp Enable ICMP pinging
--enable-delay-pools Enable delay pools to limit bandwidth usage
--enable-useragent-log Enable logging of User-Agent header
--enable-referer-log Enable logging of Referer header
--disable-wccp Disable Web Cache Coordination Protocol
--enable-kill-parent-hack
Kill parent on shutdown
--enable-snmp Enable SNMP monitoring
--enable-cachemgr-hostname[=hostname]
Make cachemgr.cgi default to this host
--enable-arp-acl Enable use of ARP ACL lists (ether address)
--enable-htcp Enable HTCP protocol
--enable-ssl Enable ssl gatewaying support using OpenSSL
--with-openssl[=prefix]
Compile with the OpenSSL libraries. The path to
the OpenSSL development libraries and headers
installation can be specified if outside of the
system standard directories
--enable-forw-via-db Enable Forw/Via database
--enable-cache-digests Use Cache Digests
see http://www.squid-cache.org/FAQ/FAQ-16.html
--enable-default-err-language=lang
Select default language for Error pages (see
errors directory)
--enable-err-languages="lang1 lang2.."
Select languages to be installed. (All will be
installed by default)
--with-coss-membuf-size COSS membuf size (default 1048576 bytes)
--enable-poll Enable poll() instead of select(). Normally poll
is preferred over select, but configure knows poll
is broken on some platforms. If you think you are
smarter than the configure script, you may enable
poll with this option.
--disable-poll Disable the use of poll().
--disable-http-violations
This allows you to remove code which is known to
violate the HTTP protocol specification.
--enable-ipf-transparent
using IP-Filter network address redirection.
--enable-pf-transparent
Enable Transparent Proxy support for systems
using PF network address redirection.
--enable-linux-netfilter
Enable Transparent Proxy support for Linux 2.4.
--with-large-files Enable support for large files (logs etc).
--enable-large-cache-files
Enable support for large cache files (>2GB).
WARNING: on-disk cache format is changed by this option
--with-build-environment=model
The build environment to use. Normally one of
POSIX_V6_ILP32_OFF32 32 bits
POSIX_V6_ILP32_OFFBIG 32 bits with large file support
POSIX_V6_LP64_OFF64 64 bits
POSIX_V6_LPBIG_OFFBIG large pointers and files
XBS5_ILP32_OFF32 32 bits (legacy)
XBS5_ILP32_OFFBIG 32 bits with large file suppor
XBS5_LP64_OFF64 64 bits (legacy)
XBS5_LPBIG_OFFBIG large pointers and files
default The default for your OS
--enable-leakfinder
Enable Leak Finding code. Enabling this alone
does nothing; you also have to modify the source
code to use the leak finding functions. Probably
Useful for hackers only.
--disable-ident-lookups
This allows you to remove code that performs
Ident (RFC 931) lookups.
--disable-internal-dns This prevents Squid from directly sending and
receiving DNS messages, and instead enables the
old external "dnsserver" processes.
--enable-truncate This uses truncate() instead of unlink() when
removing cache files. Truncate gives a little
performance improvement, but may cause problems
when used with async I/O. Truncate uses more
filesystem inodes than unlink..
--disable-hostname-checks
Squid by default rejects any host names with
odd characters in their name to conform with
internet standards. If you disagree with this
you may use this switch to turn off any such
checks, provided that the resolver used by
Squid does not reject such host names.. This
may be required to participate in testbeds for
international domain names.
--enable-underscores Squid by default rejects any host names with _
in their name to conform with internet standards.
If you disagree with this you may allow _ in
hostnames by using this switch, provided that
the resolver library on the host where Squid runs
does not reject _ in hostnames...
--enable-auth="list of auth scheme modules"
Build support for the list of authentication schemes.
The default is to build support for the Basic scheme.
See src/auth for a list of available modules, or
Programmers Guide section authentication schemes
for details on how to build your custom auth scheme
module
--enable-auth-modules="list of helpers"
Backwards compatibility alias for
--enable-basic-auth-helpers
--enable-basic-auth-helpers="list of helpers"
This option selects which basic scheme proxy_auth
helpers to build and install as part of the normal
build process. For a list of available
helpers see the helpers/basic_auth directory.
--enable-ntlm-auth-helpers="list of helpers"
This option selects which proxy_auth ntlm helpers
to build and install as part of the normal build
process. For a list of available helpers see
the helpers/ntlm_auth directory.
--enable-digest-auth-helpers="list of helpers"
This option selects which digest scheme authentication
helpers to build and install as part of the normal build
helpers/digest_auth directory.
--enable-ntlm-fail-open Enable NTLM fail open, where a helper that fails
one of the Authentication steps can allow squid to
still authenticate the user.
--enable-external-acl-helpers="list of helpers"
This option selects which external_acl helpers to
build and install as part of the normal build
process. For a list of available helpers see the
helpers/external_acl directory.
--with-samba-sources=/path/to/samba-source-tree
Path where the correct Samba source files can be
found while building winbind helpers. (defaults to
use internal copies of the headers from Samba-2.2.7)
Disable-unlinkd Do not use unlinkd
--enable-stacktraces Enable automatic call backtrace on fatal errors
--enable-x-accelerator-vary
Enable support for the X-Accelerator-Vary
HTTP header. Can be used to indicate
variance within an accelerator setup.
Typically used together with other code
that adds custom HTTP headers to the requests.
--with-maxfd=N Override maximum number of filedescriptors. Useful
if you build as another user who is not privileged
to use the number of filedescriptors you want the
resulting binary to support
После того, как вы нашли необходимый ключ, добавляем его в %configure. Например, мы хотим собрать squid с поддержкой ssl. Из помощи мы определили, что для этого, необходимо добавить два ключа --enable-ssl и --with-openssl. Вносим соответствующие изменения
Сохраняем файл и начинаем сборку.
# rpmbuild -ba --target=athlon squid.spec
Платформы для сборки: athlon
Сборка для платформы athlon
Выполняется(%prep): /bin/sh -e /var/tmp/rpm-tmp.59199
+ umask 022
+ cd /usr/src/redhat/BUILD
+ cd /usr/src/redhat/BUILD
+ rm -rf squid-2.5.STABLE11
+ /usr/bin/bzip2 -dc /usr/src/redhat/SOURCES/squid-2.5.STABLE11.tar.bz2
...
...
...
SSL gatewaying using OpenSSL enabled
Using OpenSSL MD5 implementation
...
...
...
Записан: /usr/src/redhat/SRPMS/squid-2.5.STABLE11-2.src.rpm
Записан: /usr/src/redhat/RPMS/athlon/squid-2.5.STABLE11-2.athlon.rpm
Выполняется(%clean): /bin/sh -e /var/tmp/rpm-tmp.7322
+ umask 022
+ cd /usr/src/redhat/BUILD
+ cd squid-2.5.STABLE11
+ rm -rf /var/tmp/squid-2.5.STABLE11-root
+ exit 0
Выполняется(--clean): /bin/sh -e /var/tmp/rpm-tmp.7322
+ umask 022
+ cd /usr/src/redhat/BUILD
+ rm -rf squid-2.5.STABLE11
+ exit 0
Все squid у нас собран успешно, теперь осталось только установить или обновить его.
Коммуникации и связь в израиле Какую связь выбрать туристам
Одноклассники – социальная сеть: регистрация нового пользователя через логин и пароль: правила регистрации
Как бесплатно зарегистрироваться в социальной сеть одноклассники
Обновление ПО MegaFon Login SP-AI
Как увеличить свой доход на ютуб