16.9. Форматы пакетов RPC На рис. 16.5 приведен формат запроса RPC в пакете TCP.Поскольку TCP передает поток байтов и не предусматривает границ сообщений, приложение должно предусматривать способ разграничения сообщений. Sun RPC определяет запись как запрос или ответ, и каждая запись

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

27.1.2. Структура пакетов IP и TCP Протокол IP не ориентирован на соединение, поэтому не обеспечивает надежную доставку данных. Поля, описание которых приведено в таблице 27.4, представляют собой IP-заголовок и добавляются к пакету при его получении с транспортного

4.10.1. Фильтрация пакетов Итак, основной, но не единственной задачей сетевого экрана является фильтрация пакетов. В Linux уже встроен Firewall, и вам его не надо устанавливать отдельно. Точнее сказать, их даже два: iptables и ipchains. Они позволяют контролировать трафик, который проходит

14.12.1. Дефрагментация пакетов С помощью фрагментированных пакетов хакеры производят очень много атак на серверы. В Linux можно сделать так, чтобы ОС объединяла приходящие пакеты. Если у вас монолитное ядро (без поддержки модулей), то необходимо прописать 1 в файл

Формат пакетов Как уже было сказано, в дистрибутиве Mint принят deb-формат пакетов. Будучи разработан ещё в прошлом тысячелетии для дистрибутива Debian, формат этот был унаследован от него Ubuntu, во многом предопределив успех последней. А вслед за ней - и удачливость нашего

Программа 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-пакетов состоит из следующих этапов:

1. Извлечения исходных текстов программы из архива
2. Компилирование программы из исходных текстов
3. Создание 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.

Нужно сделать небольшое замечание относительно макрокоманд %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.

Иногда встречаются полезные программы, доступные только в виде исходных кодов (и/или в виде установочных пакетов для других ОС), но есть необходимость их установки на несколько компьютеров. Чтобы не выполнять компиляцию на каждом компьютере отдельно, можно на одном подготовить установочный пакет и установить его штатными средствами на других компьютерах.
Ниже приведён пример создания RPM пакета для Fedora 21 (для других версий Fedora процедура не отличается) из исходных текстов очень приятной и полезной программы Boomaga версии 0.7.0.

Готовим инструменты сборки RPM

Готовим SPEC файл

• /etc/rpm/*
• /usr/lib/rpm
• /usr/lib/rpm/macros

Позже, когда дистрибутив 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

Полезные ссылки

Делаем 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 0.7.1-1.fc21.R - Initial version of the package

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

Я буду собирать пакет из исходников ffmpeg для AirVideoServer, который я уже рассказывал как . Я сторонник того, что бы в дистрибутиве, который использует пакетный менеджер, приложения ставились именно через него, по этому на CentOS я не люблю собирать ПО из исходников. По этой причине я решил собрать себе всё в пакеты. Сборка так же необходимых lame (он идёт уже со spec-файлов в комплекте) и x264 (под него вы сможете написать spec-файл сами, после прочтения этой статьи) не должна вызвать у вас проблем в будущем.

И так, для начала нам нужно настроить «среду» в которой мы будет собирать пакет. Не рекомендуется производить сборку пакетов из под root`а, по этому мы заведём отдельного пользователя, но а пока поставим всё необходимое ПО:

Yum install gcc gcc-c++ automake autoconf libtool yasm nasm ncurses-devel git ftp rpmdevtools

а теперь заведём специального пользователя

Useradd rpmbuild

и войдём под ним

Su - rpmbuild

выполним команду

Rpmdev-setuptree

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

Wget http://inmethod.com/airvideo/download/ffmpeg-for-2.4.5-beta7.tar.bz2

разворачиваем его

Tar -xjf ffmpeg-for-2.4.5-beta7.tar.bz2

Положим рядом конфигурационный файл с содержимым:

Nano airvideoserver.conf path.ffmpeg = /usr/bin/ffmpeg password = subtitles.encoding = utf-8 subtitles.font = Verdana folders = Movies:/home/share/films

Сюда же скачаем файл сервера:

Wget http://inmethod.com/airvideo/download/linux/alpha6/AirVideoServerLinux.jar

И init-скрипт:

Nano AirVideoServer #!/bin/bash #chkconfig: - 80 20 #description: AirVideo server # Source function library. . /etc/rc.d/init.d/functions PREFIX_DIR=/usr/local/AirVideo case "$1" in start) echo -n "Starting AirVideo server: " daemon java -jar ${PREFIX_DIR}/AirVideoServerLinux.jar ${PREFIX_DIR}/properties.conf > /dev/null 2>&1 & [ $? -eq 0 ] && success || failure echo ;; stop) echo -n "Stopping AirVideo server: " killproc java echo ;; status) status java ;; restart | reload) $0 stop ; $0 start ;; *) echo "Usage: airvideo {start|stop|status|reload|restart" exit 1 ;; esac

Теперь можно переходить к написанию нашего spec-файла для сборки.
Сначала у нас идут различные заголовки. Имя пакета, версия и релиз — имеют значение, от них будет зависеть в какую директорию будет разворачиваться исходник перед сборкой. В Source1 , Source2 и Source3 мы указываем наши 3 дополнительных файл, конфиг, сервер и init-скрипт, которые необходимо добавить в пакет при сборке.

Name: ffmpeg Version: 2.4.5 Release: beta7 Summary: ffmpeg for AirVideoServer License: GPL URL: http://inmethod.com/airvideo/ Source: http://inmethod.com/airvideo/download/ffmpeg-for-2.4.5-beta7.tar.bz2 Source1: airvideoserver.conf Source2: AirVideoServer Source3: AirVideoServerLinux.jar BuildRoot: %{_tmppath}/%{name}-for-%{version}-%{release}

%description Utility and library for encoding H264/AVC video streams for AirVideoServer.

Секция %prep отвечает за команды, необходимые для начала сборки, что бы мне не мучится с переименованием директории под формат -, я просто ключом -n указываю где лежат распакованные исходники

%prep %setup -n /home/rpmbuild/rpmbuild/BUILD/ffmpeg/

Секция %build отвечает за непосредственную сборку исходника, ключи вы можете менять на необходимые вам, как при обычной сборке и установке из исходников:

%build ./configure \ --prefix="%{_prefix}" \ --bindir="%{_bindir}" \ --libdir="%{_libdir}" \ --enable-pthreads \ --disable-shared \ --enable-static \ --enable-gpl \ --enable-libx264 \ --enable-libmp3lame

Секция %install содержит команды установки файлов пакета в систему, здесь нам необходимо дополнительно указать, куда инсталлировать наши файл конфига, сервер и init-скрипт

%install %{__rm} -rf %{buildroot} %{__make} install DESTDIR="%{buildroot}" mkdir -p $RPM_BUILD_ROOT/usr/local mkdir -p $RPM_BUILD_ROOT/usr/local/AirVideo/ install -m 644 %{SOURCE1} $RPM_BUILD_ROOT/usr/local/AirVideo/ install -m 644 %{SOURCE2} $RPM_BUILD_ROOT/etc/init.d install -m 644 %{SOURCE3} $RPM_BUILD_ROOT/usr/local/AirVideo/

Уберём за собой мусор и выполним ldconfig

%clean %{__rm} -rf %{buildroot} %post -p /sbin/ldconfig %postun -p /sbin/ldconfig

Команды в секции %files задают списки файлов и каталогов, которые с соответствующими атрибутами должны быть скопированы из дерева сборки в rpm-пакет и затем будут копироваться в целевую систему при установке этого пакета.

%files %defattr(-,root,root,-) %doc COPYING* CREDITS README* %{_bindir}/avconv %{_bindir}/avprobe %{_bindir}/avserver %{_bindir}/ffmpeg /usr/include/* /usr/lib64/* /usr/share/avconv/* /usr/local/AirVideo/airvideoserver.conf /etc/init.d/AirVideoServer /usr/local/AirVideo/AirVideoServerLinux.jar

Макрос %doc отмечает файлы документации, копирайты и прочие вещи.
На этом наш spec-файл готов, теперь нам необходимо запустить саму сборку

Rpmbuild -bb ffmpeg/ffmpeg.spec

При успешной сборке пакета, после завершения, в директории RPMS/_архитектура_/ у нас появится наш пакет ffmpeg-2.4.5-beta7.x86_64.rpm который теперь можно выложить и развернуть на любой машине.

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

Есть две машины, идентичная версия / арка 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 | xargs tar -zcvf /tmp/program.tgz

машина 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