студия rpm что это

ИТ База знаний

Полезно

— Онлайн генератор устойчивых паролей

— Онлайн калькулятор подсетей

— Руководство администратора FreePBX на русском языке

— Руководство администратора Cisco UCM/CME на русском языке

— Руководство администратора по Linux/Unix

Навигация

Серверные решения

Телефония

FreePBX и Asterisk

Настройка программных телефонов

Корпоративные сети

Протоколы и стандарты

Вам пакет нужен? Нет, я со своим.

Есть несколько способов откуда можно взять пакеты RPM: CD/DVD с программным обеспечением, CentOS Mirror, RedHat (нужен аккаунт) или любые открытые сайты репозитория.

В RPM используется несколько основных режимов команд: Install (используется для установки любого пакета RPM), Remove (используется для удаления, стирания или деинсталляции пакета), Upgrade (используется для обновления существующего пакета), Query (используется для запроса пакета) и Verify (используется для проверки пакетов RPM).

Рассмотрим это на примере. У нас есть пакет, и теперь посмотрим, что мы можем с ним делать.

Установка

Как узнать информацию о пакете RPM без установки?

После того, как мы скачали пакет мы хотим узнать информацию о пакете перед установкой. Мы можем использовать -qipoption (запрос информации о пакете), чтобы вывести информацию о пакете.

Как установить RPM пакет?

Мы можем использовать параметр -ivh для установки определенного пакета, как показано ниже.

Как проверить установленный пакет RPM?

Мы можем использовать параметр -q с именем пакета, и он покажет, установлен ли пакет или нет.

Как вывести список всех файлов для определенного установленного пакета RPM?

Мы можем перечислить все файлы установленных пакетов rpm, используя опцию -ql с командой rpm.

Как вывести список недавно установленных пакетов RPM?

Мы можем использовать параметр -qa с параметром —last, в котором будут перечислены все недавно установленные пакеты rpm.

Как установить RPM пакет без зависимостей?

Мы можем использовать параметры -ivh с параметром —nodeps для проверки отсутствия зависимостей, чтобы установить конкретный пакет без зависимостей, как показано ниже.

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

Мы можем использовать параметры -ivh –replacepkgs для замены установленного пакета.

Удаление

Как удалить пакет RPM?

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

Обновление

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

Для обновления пакета мы используем параметры -Uvh

Запрос

Как запросить все установленные пакеты?

Мы можем использовать параметры -a вместе с q для запроса всех установленных пакетов на сервере.

Как запросить конкретный пакет?

Мы можем использовать команду grep, чтобы узнать, установлен ли конкретный пакет или нет.

Как запросить файл, который принадлежит пакету RPM?

Чтобы узнать к какому пакету RPM относится файл /usr/lib64/libGeoIP.so.1.5.0. используем следующую команду.

Проверка

Как получить информацию для конкретного пакета?

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

Как проверить RPM пакет?

Мы можем проверить пакет, сравнив информацию об установленных файлах пакета с базой данных rpm, используя опцию -Vp.

Как проверить все пакеты RPM?

Мы можем проверить все установленные пакеты rpm, используя опцию -Va

Полезно?

Почему?

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

😍 Полезные IT – статьи от экспертов раз в неделю у вас в почте. Укажите свою дату рождения и мы не забудем поздравить вас.

Источник

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

Любой вебмастер понимает, насколько важно анализировать различные метрики своего веб-сайта. Это позволяет увидеть, удовлетворены ли пользователи вашим сайтом, и не пора ли его оптимизировать. Существует много разных показателей, но наиболее эффективным является, безусловно, RPM сеанса (revenue per one thousand sessions, доход за тысячу сеансов). В данной статье мы рассмотрим показатель RPM сеанса (Session RPM) и обоснуем, почему он является ключевым для издателей.

Прежде рассмотрим три важные метрики: сеансы (sessions), пользователи (users), глубина просмотра (pages views). Если для анализа трафика вы используете Google Analytics, вы наверняка их знаете. Давайте рассмотрим детальнее, что они означают.

Краткое содержание

Что такое сеансы?

Google определяет сеанс как « период времени, в течение которого пользователь активно работает с вашим веб-сайтом или приложением. К сеансу привязываются все данные об использовании: просмотры экрана, события, транзакции электронной торговли и т.д. ». Если период бездействия пользователя на сайте продолжается более 30 минут, вся последующая активность будет отнесена к новому сеансу. Если перерыв между действиями составляет менее 30 минут, сеанс не прерывается.

Вот как учитывается сеанс: когда пользователь вводит имя сайта в адресную строку браузера, активируется файл cookie сеанса (идентификатор, который маркирует конкретный сеанс данного конкретного пользователя). Если в течение 30 минут пользователь ничего не делает, сеанс истекает; когда же пользователь взаимодействует с каким-либо элементом веб-сайта, Google Analytics добавляет 30 минут к истечению срока действия текущего сеанса.

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

Что такое пользователи и глубина просмотра?

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

Измерение пользователей означает подсчет количества уникальных пользователей, просматривающих сайт. Когда пользователь впервые вводит адрес веб-сайта в адресную строку, Google Analytics создает идентификатор пользователя (cookie), который сохраняется в браузере в течение двух лет с момента последнего доступа. Обратите внимание, что cookie идентифицирует пользователя в определенном браузере. Поэтому, если человек посещает сайт с помощью Google Chrome, а на следующий день использует Safari, он будет считаться двумя разными пользователями. То же самое происходит, если он использует разные устройства, скажем, компьютер и смартфон. Кроме того, подсчет пользователей отличается от подсчета сеансов: пользователь может выполнять несколько сеансов за два года, прежде чем истечет срок его cookie.

И последнее, но не менее важное: глубина просмотра. Эта метрика учитывает количество страниц, просматриваемых пользователем. Учет глубины просмотра отличается от учета сеансов и пользователей, поскольку пользователь может просматривать несколько страниц в течение одного сеанса. Фактически если один и тот же пользователь открывает две разные страницы или даже обновляет одну и ту же страницу, глубина просмотра составит две страницы.

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

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

Что такое RPM сеанса?

RPM сеанса (revenue per one thousand sessions) означает «доход за тысячу сеансов», то есть сколько вебмастер зарабатывает на своем веб-сайте на 1000 сеансов. Вы можете рассчитать эту метрику, разделив общий доход от всех источников на количество сеансов, а затем умножив результат на 1000. Итак:

RPM = Total Revenue / Sessions * 1000.

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

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

1. Общий доход (total revenue)

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

2. CPM (и eCPM)

Показатель CPM (стоимость одной тысячи показов) обычно используется рекламодателями (действительно, он связан со «стоимостью», а не с «доходом»), но метрика довольно популярна и среди владельцев инвентаря. CPM определяет цену, которую бренд платит за покупку определенного рекламного блока. Однако высокая цена за тысячу показов не всегда соответствует общему успеху вебмастера. Например, бренд, который платит высокую цену за тысячу показов, но заполняет только 50% доступных рекламных мест, может принести вебмастеру меньше заработка, чем другой бренд, покупающий трафик по более низкой цене, но имеющий больший процент выкупа рекламных мест (fillrate).

Чтобы учесть в расчетах заполняемость мест рекламой, некоторые вебмастера используют другую метрику: eCPM — эффективную стоимость за тысячу показов, которая представляет собой соотношение между общей выручкой и рекламными запросами, умноженное на 1000:

eCPM= revenue / ad requests * 1000.

Данный метод тоже не идеален, так как он не дает широкого представления о доходах вебмастера, фокусируясь на экономической ценности отдельных рекламных блоков. Например, веб-страница имеет один рекламный блок с eCPM в размере 2 евро. На эту же страницу вебмастер добавляет еще один рекламный блок с eCPM 1 евро. Сравнение eCPM двух блоков подчеркнет низкую стоимость второго блока, а не дополнительный доход, который он позволил извлечь.

3. RPM страницы (Page RPM)

Как мы говорили ранее, существует разница между сеансами и просмотрами страниц. Некоторые владельцы средств массовой информации (в основном те, кто использует AdSense) измеряют эффективность монетизации инвентаря с помощью показателя RPM страницы, что означает «доход на 1000 страниц (просмотров)». По сравнению с CPM и eCPM, которые ориентированы только на ценность отдельных рекламных блоков, RPM страницы является более «продвинутой» метрикой, поскольку она учитывает действия пользователей. Тем не менее, и этот показатель имеет важное ограничение: он не учитывает негативное влияние, которое может оказывать изменение юзабилити на количество просмотров страниц и, в конечном счете, на доход.

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

4. RPM сеанса объявлений (Ad session RPM)

AdSense представил метрику RPM сеанса объявлений, которая очень похожа на показатель RPM сеанса. Эта метрика означает «доходы на 1000 сеансов AdSense» и рассчитывается путем деления общего дохода на количество сеансов AdSense, умноженное на 1000. Очевидно, что основным ограничением этого метода является то, что он рассматривает только кампании AdSense, поэтому, если вебмастер разместит рекламный блок другого партнера, RPM сеанса объявлений будет уменьшаться, даже если фактического снижения выручки не произойдет. Кроме того, эта метрика не учитывает влияние некоторых внешних факторов, таких как использование блокировщиков рекламы. Действительно, если многие пользователи начнут устанавливать блокировщики рекламы, RPM сеанса объявлений, вероятно, останется без изменений, в то время как общий доход снизится.

RPM сеанса: почему это ключевой показатель для вебмастера

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

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

Clickio предлагает вебмастерам глубокий анализ RPM сеанса. Проводя A / B тесты, мы тестируем доходность различных вариантов верстки страниц и вывода рекламных блоков. Свяжитесь с нами, если хотите получить дополнительную информацию.

Источник

Студия rpm что это

LES MILLS RPM™ – это супермотивирующая и часто вызывающая зависимость сайкл-тренировка, которая сжигает много калорий и укрепляют сердечно-сосудистую систему. RPM идеально подходит для новичков, поскольку уровень нагрузке можно регулировать самостоятельно.

Хотите узнать больше о программе RPM? Посмотрите наше демо-видео ниже

Что такое RPM?

Это энергичная низкоударная тренировка, сжигающая до 675* калорий за занятие и укрепляющая сердечно-сосудистую систему. Крутя педали под модную качающую музыку, в едином ритме с остальной группой, вы преодолеете несколько интервалов на максимальной мощности. Тренировка в группе мотивирует держать скорость и постоянно улучшать свои результаты.

Почему программа RPM эффективна для членов вашего клуба?

RPM – это идеальный выбор для начинающих, поскольку велотренажер позволяет контролировать уровень нагрузки. Новички могут поддерживать скорость остальных, в то время как более продвинутые райдеры могут поднять сопротивление, бросив себе тем самым вызов. Инструкторы LES MILLS знают, как сделать так, чтобы тренировка была эффективной, вдохновляющей и безопасной для человека любого уровня подготовки.

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

Почему программа RPM эффективна для вас?

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

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

Хотите добавить RPM в расписание вашего клуба? Свяжитесь с нами

Источник

Построение пакета RPM для Rosa Linux на практике

Если Вы уже давно пользуетесь операционной системой Linux и хоть немного разбираетесь в программировании, рано или поздно Вам может понадобиться собрать программу из исходного кода. Может быть, нужной программы не окажется в репозиториях дистрибутива. Или в этих репозиториях программа старой версии, а Вам нужна самая свежая. А может, Вы создали новую программу и хотите поделиться ей с другими пользователями.

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

Надеюсь, эта статья поможет быстрее разобраться со сборкой пакета RPM для Rosa Linux или для другого дистрибутива, использующего менеджер пакетов RPM (Mandriva, RedHat). Или хотя бы подскажет, где искать информацию.

Здесь я покажу, как создавать пакеты RPM на своём локальном компьютере, на простом примере. Будем собирать программу xkb-switch в операционной системе Rosa Linux. Исходники программы будем брать с GitHub.

Оглавление

Немного о Rosa Linux

Rosa Linux — дистрибутив, созданный и поддерживаемый российскими разработчиками. Он сделан на основе Mandriva, но с некоторыми особенностями. Я использую 32-битную версию Rosa Fresh R8, которая выпущена в 2014 году. Сейчас версия R8 уже не поддерживается разработчиками (репозитории для неё не обновляются), но хорошо работает на моём ноутбуке, поэтому не хочется устанавливать новую версию.

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

Построение пакетов в Rosa Linux немного проще, чем в некоторых других дистрибутивах, основанных на RPM. Некоторые моменты автоматизированы и не нуждаются в настройке.

Немного об xkb-switch

Мне понравилась идея использовать плагин для текстового редактора Vim — xkbswitch, о котором есть статья на Хабре. Он автоматически переключает раскладку клавиатуры на английский язык при выходе из режима ввода, и обратно — на тот, на котором вводили текст в прошлый раз — если войти в режим ввода снова. Для работы этого плагина нужна программа xkb-switch, которая позволяет переключать раскладку клавиатуры из командной строки и из плагинов для редактора Vim. В репозиториях Rosa Linux R8 этой программы не оказалось (и, скорее всего, никто не будет его добавлять, ведь дистрибутив уже старый, а программа xkb-switch не слишком популярна).

Настройка, доработка, проверка программы

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

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

Проверяем исходный код без своего профиля в GitHub

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

/Projects/cpp для исходных кодов на C++):

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

Файл xkb-switch.zip потом нужно будет использовать для сборки пакета.

Проверка с сохранением проекта в свой профиль GitHub

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

Сначала нужно «форкнуть» оригинальный проект в свой GitHub. После этого, как в прошлом способе, клонируем проект к себе на компьютер, но уже из своего репозитория (в моём случае, имя пользователя — alexandersolovyov):

После этого можно сделать pull-request, если это нужно.

Можно сделать ссылку на оригинальный репозиторий:

И потом обновлять основную ветку своего репозитория, чтобы она соответствовала оригиналу:

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

Но, как подсказал пользователь specblog, вообще-то так делать неправильно. Лучше передать свои изменения в виде патчей. Для этого нужно создать файлы патчей из изменений в своей ветке и скопировать их в папку с исходниками для сборки пакета (

/rpmbuild/SOURCES/ ). Потом нужно будет указать их в спек-файле. Это мы рассмотрим немного позже, но если хотите — можно прочитать здесь. Если Вы не знаете, как создавать патчи, — можно заглянуть под спойлер.

Создание патчей

Патчи, они же Заплатки — это файлы, в которых записаны изменения в исходном коде программы. Их используют как альтернативу командам git pull и git push для связи между локальными репозиториями кода в том случае, если «вытягивать» изменения из удалённого репозитория не удобно, или история изменений проекта и принципы работы с ним такие, что лучше использовать патчи.

Теперь нужно сохранить изменения в виде файлов патчей в папку

/rpmbuild/SOURCES (если Вы используете не Rosa Linux, путь к папке SOURCES может быть другим). Например так (подразумеваю, что мы находимся в папке проекта — например,

/Projects/cpp/xkb-switch — и на ветке cmake_corrections ):

А можно вспомнить (или посмотреть), сколько коммитов назад мы ответвились от основной ветки, и сделать патчи на определённое количество коммитов назад. Например, если мы сделали два коммита, команда будет такая:

Можно указать диапазон коммитов, из которых нужно сделать патчи, поставив две точки между ссылками на начальный и конечный коммит:

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

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

/rpmbuild/SOURCES каждый раз перед тем, как собирать пакет с другой программой или пакет новой версии.

Подготовим «рабочее место» для создания пакета

Для начала нужно создать структуру каталогов. Вся сборка происходит в папке rpmbuild в домашней папке пользователя. Создадим начальную структуру каталогов и перейдём в папку для спек-файлов:

Для Rosa Linux этого достаточно: остальные папки будут созданы автоматически.

В другом дистрибутиве для построения пакета может использоваться другое расположение файлов. А ещё, может быть, придётся создать всю иерархию папок вручную. Ищите информацию для Вашего дистрибутива, если Вы используете не Rosa Linux. Например, вот так это может выглядеть в Red Hat.

Если после сборки программы Вы захотите собрать ещё одну или ту же самую, но другой версии, то нужно будет удалить все файлы из папки

Начнём создавать спек-файл

Основа построения пакета RPM — так называемый спек-файл. Этот файл содержит инструкции для программы rpmbuild (вернее rpm ), необходимые для сборки пакета.

Создадим файл xkb-switch.spec в папке

Немного о синтаксисе спек-файла

Заголовок спек-файла

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

Release:
Номер версии самого пакета. Отображает, который раз собирается пакет с программой одной и той же версии. В нашем случае это «1», так как никто раньше не собирал программу этой версии. В идеальном случае, если мы уже пытались собрать пакет и сборка доходила до конца (даже если были ошибки), то после каждой новой попытки нужно увеличивать это число на 1 и при этом не удалять старые собранные пакеты из папок rpmbuild/RPMS и rpmbuild/SRPMS : рядом будут созданы новые пакеты с новым номером сборки. Наверное, так нужно делать если использовать специальный сервер для сборки. Мы же используем свой компьютер и вместо этого будем очищать папки. Если пакет с программой такой версии уже есть в репозиториях дистрибутива Linux, но Вы собираете с другими настройками, то лучше указать номер релиза на 1 больше, чем у того пакета.

URL:
Адрес в интернете, откуда можно скачать оригинальный исходный код программы. Он будет указан при просмотре информации о пакете RPM. Этот пункт заполнять не обязательно, но мы укажем: https://github.com/ierton/xkb-switch

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

/rpmbuild/SOURCES (рядом со скачанным архивом с исходниками). Имя каждого файла нужно писать без пути к нему. Здесь не обязательно указывать все файлы патчей, — можно только те, которые Вы хотите применить.

AutoReq:, AutoProv:
Если Вы собираете программу, которая написана на языке, с которым менеджер rpm плохо знаком, или которая является проприетарной, и зависимости не определяются правильно автоматически, то можно отключить автоматическое определение Возможностей (с помощью AutoProv: no ) и/или Зависимостей (с помощью AutoReq: no ).

%description
Этот блок уже не является частью заголовка, но связан с ним. Он добавит полное описание программы в пакет RPM. После него должна быть оставлена пустая строка. Описание может быть таким:

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

Подготовка исходников

Можно сразу попробовать собрать пакет, останавливаясь после выполнения блока %prep :

Выполним наш скрипт

Подробнее о добавлении патчей можно почитать на сайте Maximum RPM.

Теперь можно двигаться дальше.

Компиляция

В конце вывода видим exit 0 : всё сделано без ошибок.

Вообще, в блоках команд не обязательно использовать только одни макросы. Можно добавить любые команды shell (то есть bash или zsh, или что там у Вас). Команда rpmbuild во время сборки перемещается по папкам, поэтому нужно добавить переход в правильную рабочую папку перед своей командой. В этих командах shell можно использовать константы спек-файла — как и в любом другом месте этого файла. (Использование констант мы увидим ниже.)

Если Вам нужно собрать какой-нибудь необычный пакет, тогда, скорее всего, придётся использовать в блоке %build команды shell вместо макросов.

Инсталляция

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

Здесь полное_имя_пакета будет состоять из имени, указанного с помощью опции Name: в заголовке спек-файла, версии программы ( Version: в спек-файле), номера релиза ( Release: в спек-файле), названия дистрибутива, его версии и архитектуры процессора.

В конце псевдоинсталляции проверяется список файлов, которые нужно будет добавить в пакет RPM. В нашем спек-файле его ещё нет, поэтому будет сообщение об ошибке.

Упаковка файлов

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

Чтобы указать, какие файлы должны быть добавлены в пакет, нужен блок %files в спек-файле. Мы удалили строки, нужные для поддержки нескольких языков, поэтому такого блока в файле нет. Создадим его.

Во многих системах принято располагать блок %files внизу спек-файла. Это логично, ведь он выполняется последним. Но в Rosa Linux его принято писать сразу перед блоком %prep (и разделительной строкой-комментарием в нашем случае). Так все настройки, касающиеся подготовки файлов, будут находиться в конце файла, а то, что касается сборки пакета из этих файлов — в верхней части. Это особенно удобно если нужно построить несколько пакетов одним спек-файлом (да, так тоже можно делать, и мы рассмотрим это ниже).

В блоке %files должен быть список файлов, которые должны быть в пакете RPM. Итак, создадим блок над разделительной чертой:

Теперь попробуем построить пакет полностью:

`xkb-switch.i586: E: incoherent-version-in-name (Badness: 50) 1`
Ошибка: версия в имени библиотечного пакета указана неверно.

`xkb-switch.i586: E: executable-in-library-package (Badness: 1) /usr/bin/xkb-switch`
Ошибка: в библиотечном пакете находится исполняемый файл.

Всё понятно? Не думаю. Давайте разберёмся подробнее, что здесь происходит.

Что такое rpmlint

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

Виды пакетов RPM для Rosa Linux

Пакеты для Rosa Linux делятся на 6 видов. В идеальном случае, каждый собранный пакет должен соответствовать только одному из этих видов.

Наш результат

Теперь всё стало яснее.

В результате у нас получился такой спек-файл:

Если нужно разделить пакет на части

Может понадобиться разделить проект на несколько пакетов — например, если библиотека из этой программы будет использоваться другой программой. Чтобы рассмотреть такой вариант, давайте представим, что нам нужно разделить файлы проекта xkb-switch на 3 пакета: исполняемый, библиотечный и для разработки. Тогда:

Для этого нужно сделать изменения в спек-файле. О том, как это сделать,
можно узнать из соответствующего раздела онлайн-книги Maximum RPM. Также может быть полезен пример спек-файла для libxkbfile и Политика оформления библиотек Rosa Linux.

Давайте попробуем это сделать.

Добавим немного макросов

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

Макрос %mklibname берёт строку «lib», добавляет к нему первый аргумент, а к тому что получилось — второй аргумент (и все следующие). То есть значением константы % будет «lib» + «xkbswitch» + (значение константы %) = libxkbswitch1 — имя пакета библиотеки.

Немного изменим заголовок

Приведём строку с опцией Version: к виду

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

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

Определим пакеты библиотек

В Rosa Linux принято объявлять под-пакеты под блоком %description заголовка спек-файла. Определим пакет библиотеки libxkbswitch1 так:

Ниже объявим пакет для разработчиков:

Определим файлы для пакетов

Таким образом мы определили, что:

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

Решение дополнительных проблем

Итак, чтобы убрать предупреждение об отсутствии документации, можно притвориться, что документация к библиотекам хранится в файле README.md проекта. Добавим его в блоки %files для пакетов библиотеки и разработки — с помощью макроса %doc :

Здесь не нужно указывать полный путь. Рабочая папка макроса %doc — папка с распакованными исходниками. Поэтому в документацию пакетов будет добавлен файл

Можно попробовать очистить папки и собрать пакеты заново, но… предупреждение об отсутствии зависимости всё равно останется. Если проверить зависимости пакета libxkbswitch-devel ещё раз, то увидим, что зависимость успешно добавляется. Скорее всего сообщение остаётся потому, что в нашем пакете для разработки нет заголовочных файлов, и rpmbuild не может определить эту зависимость автоматически.

Спек-файл, который у нас получился (с файлом README.md в качестве документации библиотек), — под спойлером:

Вывод

Мы рассмотрели, как можно построить несложный пакет RPM для операционной системы Rosa Linux (и других систем использующих такой же менеджер пакетов). Также мы научились создавать несколько связанных пакетов, используя один спек-файл. Конечно, здесь не затронуто очень много тем — таких, как применение патчей, использование настроек rpmrc, или сборка пакетов на сервере ABF вместо локального компьютера, — но это было бы слишком много для одной статьи.

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

Основные команды

Команды для сборки пакета

Проверка готового пакета

Источник