Src rpm что это
Src rpm что это
Из готового тарбола (если он учитывает все нужные патчи) можно получить исполняемые программы с помощью следующих команд:
1 разархивировать тарбол:
Создаем папку, куда будем разархивировать тарбол,
Копируем туда тарбол
Непосредственно разархивируем в папку:
— разархивация архивов типа tar.gz и tgz
— разархивация архивов типа tar.bz и tbz
Переходим в папку с разархивированным тарболом
2 конфигурим пакет
3 Создаем пакет:
4 Устанавливаем пакет
7.2 Установка программ из сорца (.src.rpm)
В дистрибутивах Red Hat, Mandrake, Suse, AltLinux, ASP Linux и некоторых других, программы (состоящие, как правило, из нескольких файлов) распространяются объединенными в пакеты формата RPM (RedHat Packet Manager). С помощью программы rpm можно легко устанавливать, модифицировать, удалять и создавать пакеты программного обеспечения, а также получать о них разнообразную информацию. Все эти дистрибутивы (кроме программы начальной установки) состоят из таких пакетов. Каждый пакет определяется именем программы, номером ее версии и номером версии релиза этой программы дистрибутива, а также архитектурой пакета. Например, bash-2.0.5-alt2.i586.rpm: в этом пакете
Далее приводятся возможные параметры.
Установка пакета.
Обновление пакета.
Удаление пакета.
то есть, например, для пакета klyx:
Если в процессе удаления пакета произойдет нарушение зависимостей, программа rpm сообщит об этом.
Информация о пакете.
Если надо установить два или более пакетов, зависящих друг от друга, то установите их одновременно:
Fedora: сборка пакетов из src.rpm
Записная книжка рассеянного [в пространстве и времени] программиста
Fedora: сборка пакетов из src.rpm
Чаще всего то не требуется обычному пользователю. Но бывает ситуации, когда пакет собран с поддержкой библиотеки исключенной из дистрибутива.
Недавно это случилось с chromium в centos, а с драйверами от epson случается постоянно.
А еще это может потребоваться если мы хотим поставить пакет, который распространяется только в src.rpm.
Устанавливаем тулчейн для сборки
Нам потребуется группа пакетов для сборки RPM
Подготавливаем окружение
Команда подготовит необходимую структуру папок в домашнем каталого.
Достаем пакет с исходниками
Вы же видели репозитарии source (например, russianfedora-nonfree-updates-testing-source. Все эти репозитарии откючены в конфиге и включать их нет необходимости потому что пакеты из них обычным способом поставить нельзя.
Установка src.rpm осуществляется под аккаунтом пользователя и производится в каталог rpmbuild, который был подготовлен выше.
Сначала пакет нужно скачать (либо руками, либо из репозитария). В случае репозитария это делается через dnf.
Установка зависимостей
Для сборки многим пакетам требуются заголовочые файлы или библиотеки для линковки, которые принадлежат другим пакетам. Все зависимости описываются в самом файле с исходниками и для их установки нужно только вызвать команду builddep.
Установка исходников
Теперь пакет нужно поставить (не забываем, что все операции выполняются под аккаунтом текущего пользователя, а не рута).
Сборка
Для сборки следует проверить, что спецификация нужного пакета появилась в каталоге
В случае imagescan весь процесс происходит очень болезненно. Поэтому я пропущу детали поиска решения и лишь покажу процесс.
Дополнительная опция –define позволяет определять и переопределять макросы, которые будут использоваться тулчейном.
Таких ошибок встретится превеликое множество из-за довольно старых исходников, которые не адаптированы под свежий стандарт c++. Решением будет установка целой группы флагов через глобальную переменную CXXFLAGS.
Флаг debug_package добавлен из-за того, что попытка сборки пакета debugpackage приподит к ошибке из-за отсутствия нужных определений в файле спецификации.
Установка пакета
Литература
RSS feed This page was generated by GitHub Pages.
Src rpm что это
При установке пакета rpm записывает информацию о нем в свою базу данных, что и позволяет в дальнейшем удалять пакет, просматривать информацию о нем и т.д.
Режимы работы rpm
Если вызвать rpm без параметров, то он покажет «краткий» список ключей. Обычно же формат вызова rpm такой:
КлючРежима, указываемый первым, определяет режим работы. Самые частоиспользуемые режимы перечислены в таблице.
Установку, обновление и удаление пакетов мы рассмотрели ранее, поэтому сейчас остановимся лишь на общих параметрах, получении информации и проверке.
Ключи и параметры, общие для разных режимов
В аргументах обычно используется два варианта ссылок на пакеты.
Можно указывать не один файл-пакета или пакет, а сразу несколько, разделяя их пробелами.
Получение информации
Какому пакету принадлежит файл
А как там назывался пакет.
Другой пример («к чему там относится afterstep?»):
Где же был этот файл.
Аналогично иногда возникает необходимость найти некий файл, имя которого помнишь весьма приблизительно, а уж в какой он лежит директории.
Информация о неинсталлированном пакете
Перед установкой нового пакета обычно имеет смысл посмотреть информацию о нем и/или список содержащихся в нем файлов.
В вышеприведенном примере видно, что данный пакет установить не удастся, как минимум потому, что установленная версия пакета gtk+ слишком старая.
Проверка
При нахождении различий печатается ключевая строка, с обозначением отличий и имя файла, в котором они найдены.
Сравниваются следующие параметры: 5 Контрольная сумма (подсчитанная по алгоритму MD5) S Размер файла L Куда указывает символьный линк (если проверяемый файл является симлинком) T Время модификации D Устройство (раздел), на котором расположен файл U Владелец G Группа-владелец M Права доступа
Проверку лучше выполнять как » root «, так как некоторые файлы (например, /usr/X11R6/bin/xterm ) могут быть недоступны на чтение другим пользователям и для них всегда будет выдаваться несовпадение по контрольной сумме.
Как видно из этого примера, в некоторых файлах обязательно будут отличия, поскольку тот же /etc/passwd изменяется при создании и изменении пользователей.
Где еще брать информацию про rpm
Сборка rpm пакетов и настройка своего репозитория
В данной статье будет подробно описан процесс создание rpm пакетов и организация репозитория. Прошу всех, кому интересна данная тема, пройти под кат.
Я взялся писать крайне подробно, так что Вы можете пролистать очевидные для Вас вещи.
Оглавление
Установка системы
Наш сервис начинается с момента установки на него операционной системы. Естественно, что для сборки rpm пакетов мы выбираем rhel дистрибутив. В данном случае, был выбран CentOS 7.
Скачать CentOS
Создадим директорию, где будет лежать образ и перейдем в нее:
Далее можно непосредственно скачать образ и необходимые для проверки файлы:
или посредством torrent`а с помощью программы aria2, которую для начала установим:
Проверить образ
Скачать образ мало, нужно проверить его целостность и достоверность, что мы и сделаем.
Скачаем ключ для CentOS 7:
Посмотрим на ключ и импортируем его:
Проверим подпись файла, с контрольной суммой образа:
Как мы видим — все отлично и теперь можем проверить сам образ на целостность:
Запись образа на носитель
После того как мы убедились в целостности образа и его достоверности, неплохо было бы его уже записать и установить! Так сделаем это, но вначале определимся, на что записывать будем.
Запись образа на диск
Для записи данного образа, нам понадобится двухсторонний DVD. Допустим мы его нашли и записываем, установив предварительно wodim:
Запись образа на флешку
Двухсторонний DVD это как то архаично, так что возьмем флешку на 16 гб и запишем образ на нее, но прежде /dev/sda тут — это флешка, а у Вас она может быть другой. Смотри команду fdisk:
Если status=progress не поддерживается, то по старинке:
а можно воспользоваться pv:
Установка
Как поставить Centos 7, решать Вам, тут и за RAID подумать можно и за LVM и много чего еще,
я ставил минимальный пакет.
Процесс установки можно посмотреть в этом ролике.
Преднастройка
После установки системы, нам необходимо настроить наш сервер.
Обновление и установка пакетов
В начале мы обновим все установленные пакеты, далее установим репозиторий epel, в котором есть много что полезного для нас:
Следующим шагом установим группу пакетов, которые понадобятся нам для сборки, а так же ряд пакетов необходимые для развёртывания репозитория.
Для того чтобы комфортно и безопасно управлять сервером настроим SSH.
Безопаснее пользоваться ключами, по этому мы и создадим себе ключи для доступа к серверу на своем рабочем компьютере:
и добавим ключ на сервер:
Необходимо еще закрутить гайки в самой службе. Создадим копию файла конфигурации и приступим к редактированию:
В файле стоит добавить/изменить/раскомментировать следующие строки:
Межсетевой экран
Важно ограничить доступ к нашему серверу. По этой причине настроим межсетевой экран:
Тут мы добавили наши службы http https ftp для доступности извне и ssh, но только для сети 192.168.0.0/28.
Подготовка площадки сборки
Подготовим саму площадку для сборки. Стоит отметить, что вернее всего сборку производить на отдельном виртуальном хосте, активно используя технологию snapshot’ов, но тут я опишу все в едином целом. Так же для сборки нужно выделить отдельного пользователя, не являющемся администратором (т.е. sudo ему недоступно).
Создание директорий
Создаем необходимые директории:
Настройка PGP подписи
Наши пакеты, которые мы соберем, необходимо подписать, что будет обеспечивать целостность и достоверность.
Ключ будем использовать свой или если его нет, то создадим. Создавать ключ стоит на своем рабочем компьютере.
Создадим ключ, если его у нас нет:
Нас попросят ответить на ряд вопросов:
тип ключа, выбираем (1) RSA and RSA (default), размер ключа: 4096, срок действия: 6m, наше имя: Alexander F. Mikhaylov, Email: chelaxe@gmail.com, комментарий, тут можно указать для чего нам ключ: repo и ждем.
Сохраняем наш приватный ключ:
Создадим ключ для отзыва:
Экспорт открытого ключа на keyserver:
Теперь ключ можно и импортировать на наш сервер:
Смотрим где находится gpg утилита:
и настроем файл для подписи пакетов:
Создаем репозиторий
Теперь организуем сам репозиторий.
Создадим директорию, где будем хранить пакеты:
Экспортируем ключ в репозиторий:
Создаем сам репозиторий и подписываем метаданные:
Пакет для репозитория
Собираем пакет для автоматической установки репозитория в систему.
Файл репозитория для yum:
Экспортируем ключ для пакета:
Собираем все в архив:
Создаем SPECS файл для пакета:
На этом этапе нас спросят пароль от нашего PGP ключа.
Копируем созданный пакет в репозиторий и обновляем его:
Не забываем подписать метаданные:
Теперь установим наш репозиторий в систему:
После установки должен появиться репозиторий chelaxe и PGP ключ:
Самое важное тут это SPEC файлы, расписывать о них не стану, но предоставлю ряд ссылок:
и одна полезная команда:
она отобразит готовые макросы для сборки.
Собираем Tmux
Теперь соберем, для примера, что нибудь полезное. Собирать будем tmux — терминальный мультиплексор, без которого работать мне не комфортно. Стоит отметить tmux есть в base репозитории CentOS 7, но версия там 1.8, а мы соберем 2.7. Так же у пакета из base репозитория есть зависимость libevent, мы же соберем tmux со статическими библиотеками последних версий.
Готовим исходники
Скачиваем исходники tmux и необходимых библиотек:
Экспортируем GPG ключи для проверки исходников:
Подготовим файл конфигурации tmux:
Готовим SPEC файл
Этот файл будет интереснее предыдущего SPEC файла:
Сборка
Собираем пакет и добавляем его в репозиторий:
Не забываем подписать метаданные:
Смотри что и как получилось:
Установка и запуск
Устанавливаем наш пакет:
Запускаем tmux и радуемся:
Собираем fbida
Собирать будем fbida — комплект приложений для просмотра изображений в консоли. Данный пакет не нашел под Centos 7.
Готовим исходники
Скачиваем исходники fbida:
Экспортируем GPG ключи для проверки исходников:
Готовим SPEC файл
В этом SPEC файле будет больше зависимостей:
Сборка
Собираем пакет и добавляем его в репозиторий:
Не забываем подписать метаданные:
Установка и запуск
Устанавливаем наш пакет:
Настройка доступа по http/https
Теперь обеспечим доступ к нашему репозиторию по http/https.
Настройка
Первым делом настроем наш Apache:
Далее необходимо добавить/изменить/раскомментировать следующие строки:
Запускаем службу и прописываем ее в автозапуск:
Настраиваем наш репозиторий:
Т.к. в Centos 7 у нас Apache 2.4.6, а не 2.4.8, то параметры Диффи-Хеллмана необходимо вшить в сертификат:
По этой же причине с HTTP/2 у нас ничего не получится, но теперь вы можете собрать сами свежий Apache и воспользоваться HTTP/2.
Проверим конфигурацию и перечитаем конфигурацию:
Сертификат от Let’s Encrypt
Пока у нас свой сертификат и это не красиво, так что получим сертификат от Let’s Encrypt:
При ответе на вопросы, выбираем использование rewrite для перенаправления всех на https. В результате в файле изменяться строки у VirtualHost для http:
и у VirtualHost для https:
Строку Include /etc/letsencrypt/options-ssl-apache.conf закомментируем.
Тут стоит напомнить о необходимости добавить файл с параметрами Диффи-Хеллмана в конец сертификата:
И изменить заголовок HKPK (HTTP Public Key Pinning):
И изменим соответственно строку в конфигурации:
Проверим конфигурацию и перечитаем конфигурацию:
Есть еще одна проблема. Для обновления сертификата добавим запись в крон:
Но этого не достаточно, нужно еще дописать автоматическое добавление файла с параметрами Диффи-Хеллмана и параметры HKPK (HTTP Public Key Pinning).
для исключения в отображении на сайте.
Для vsftpd можно использовать опции:
Тут можно используя модуль mod_autoindex Apache настроить внешний вид. Завернуть в noscript тег и используя html5, css3, javascript, jquery, bootstrap, backbone, awesome сделать конфетку, как это сделал я:
Вот что будет при использовании в браузере без поддержки javascript или с отключенным:
Настроить внешний вид листинга через mod_autoindex или в nginx:
Настройка доступа по ftp
Запускаем службу и прописываем ее в автозапуск:
Заключение
Собственно на этом все. Надеюсь, данный мануал будет Вам полезен.
Содержание
Подготовка к сборке и обзор spec-файла
В %
Также вы можете встретить без исходного кода. Обычно их создают для проприетарных программ, которые нельзя включать в дистрибутив (исходников нет, а бинарник каким-то образом нужно переделать либо просто запрещено размещать на зеркалах дистрибутива лицензией). Внутри этого пакета находится обычно только spec-файл, а бинарник скачивается и, при необходимости, модифицируется, в процессе установки пакета (например, в post-скрипте, о котором речь пойдет ниже).
Что нужно сделать, чтобы можно было собирать пакеты из-под обычного пользователя? Первым делом нужно создать в своём домашнем каталоге файл директорию rpmbuild со следующей структурой:
В РОСЕ не принято писать сборщика пакета и вендора в spec-файлах; эти значения выставляются автоматически системой сборки ABF. Также ABF автоматически подписывает собранные пакеты ключом соответствующего репозитория. Поэтому эти вопросы мы здесь затрагивать не будем.
Spec-файл состоит из секций и шапки:
Summary — краткое описание пакета, Name — название, Version — версия, Release — релиз. Последним трем тегам соответствуют макроопределения %
Далее, License — лицензия, под которой распространяется программа (обычно указано в самом пакете). Раньше в ходу был также тег Copyright, но сейчас он не используется. URL — сайт программы, Group — группа, в которую будет входить данный пакет. Обычно следует прикинуть на что этот пакет похож, и посмотреть группу похожего пакета. Придумывать группу самому не стоит, лучше посмотреть в список имеющихся.
BuildRequires — секция, в которую через запятую или через пробел прописываются пакеты, которые требуются для сборки нашей программы. Почерпнуть их можно из каких-нибудь файлов README и INSTALL (хотя там редко бывает что-то полезное по этому поводу), из процесса конфигурации (на данный момент обычно это скрипт configure ) и из самого процесса сборки (иногда configure что-нибудь пропустит и сборка остановится).
Requires — в эту секцию записываются пакеты или файлы(!), которые будет требовать данный пакет при установке. При сборке в зависимости автоматически пропишутся все библиотеки, которые наш пакет потребует, но вы также можете указать пакеты вручную. Rpm также автоматически прописывает зависимости perl, python, mono и некоторые другие (все эти зависимости прописываются не в spec-файл разумеется, а в сам пакет). Если вам не нужно, чтобы зависимости прописывались автоматически, следует прописать в spec-файл новый тег AutoReq: no. Обычно его прописывают при сборки проприетарных программ, так как rpm добавляет внутренние зависимости из собираемой программы.
Есть ещё несколько полезных тегов, которые здесь не используются.
— другие названия, помимо %
— перечисляются пакеты, которые конфликтуют с текущим. Подразумевается что указанные пакеты нужно вручную удалить, перед установкой нашего. Также используются конструкции со знаками сравнения и версиями (см. выше).
— архитектура, под которую будет собираться наш пакет. Если эта опция не указана, то пакет соберётся под текущую архитектуру. Обычно эту опцию указывают для того, чтобы собирать пакет архитектуры noarch, то есть пакет, в котором нет бинарников.
— архитектуры, под которые данный пакет может быть собран. Обычно используется при сборки модулей к ядру.
На этом шапка заканчивается и начинаются отдельные секции.
Описание главного пакета, того, у которого будет имя %
Описание второго пакета
Секция %prep в ней начинается подготовка к сборке. %setup распаковывает исходники. Опция -q не показывает вывод распаковывания архива. Опция -a1 используется для распаковки %
Секции для установочных скриптов. Вообще их бывает несколько. %pre — выполняется перед установкой, %post — после установки, %preun — перед удалением, %postun — после удаления. В нашем примере при удалении удаляются схемы Gconf. Здесь мы предполагаем, что в пакете только одна схема и ее имя совпадает с именем пакета. Обратите внимание, что для удаления схем мы вызываем специальный макрос; этот макрос раскрывается rpmbuild РОСЫ в набор необходимых команд оболочки Shell, которые, собственно, и удаляют схему. Установка схем при установке пакета выполняется автоматически за счет файловых триггеров RPM.
Для каждого пакета могут быть свои скрипты, поэтому следует также почитать документацию. Если никаких скриптов для правильной работы не нужно, то и секции эти не следует использовать. В этих секциях можно применять bash-скрипты (впрочем как и в любых других секциях).
В секциях %files мы должны указать какие файлы должны быть упакованы в пакеты. Все файлы должны быть оговорены, в противном случае rpmbuild выдаст сообщение о неупакованных файлах.
Опцией -f указываются файл, содержащий список обрабатываемых файлов. В нашем случае этот файл содержит пути к файлам локализации. Вы в принципе можете создать свой файл и подсунуть его.
Для определения каталогов используются специальные макроопределения.
Далее просто перечисляются файлы.
Макроопределения
Теперь пора познакомиться поближе с макросами и переменными. Допустим, мы собираем пакет из SVN, в данном случае в релиз обычно включается дата ревизии. В самом начале spec-файла нужно определить переменную date:
Крайне популярным макроопределением является конструкция
Как уже отмечалось выше во всех секциях spec-файла вы можете использовать любые команды Shell, включая for, while, if и др.
Сборка пакета
После этого пакет соберётся (или не соберётся, а вывалится с ошибками), и в подкаталогах каталога RPMS появятся бинарные пакеты, а в каталоге SRPMS появится исходник.
Если необходимо собрать только бинарник или только исходник, то вместо -ba следует использовать -bb и -bs соответственно. Из полезных параметров rpmbuild можно отметить -clean (удалить весь мусор), -rmsource (удалить исходники из каталога SOURCE ) и -target=архитектура (собрать пакет под конкретную архитектуру).
Можно также выполнять сценарии только в определённой секции. Описывать подобные параметры мы здесь не будем, см. man rpmbuild.
Сборка RPM пакета из уже установленного в системе
Иногда случается ситуация, что какой-то пакет уже установлен в системе (может быть в очень старой системе) и очень хочется получить rpm’ку с ним, а она как раз и не сохранилась. Также может захотеться собрать по быстрому пакет с изменёнными под ваши нужды конфигурационными файлами.
Для решения этой проблемы следует воспользоваться утилитой rpmrebuild. Эта написанная на bash утилита доступна в contrib-репозитории РОСЫ.
Работать с ней крайне просто. Нужно отдать всего лишь команду:
Если какой-либо файл был изменён, то вам об этом сообщат, но процесс сборки не прервётся.
Rpmrebuild обладает огромным количеством параметров, например, вы можете изменять release пакета, changelog, скрипты, секции Requires, описания пакета и многое другое. Можете даже просто напросто изменить spec-файл, который скрипт сгенерирует сам. Он правда будет немного страшный, но это все же лучше, чем ничего.