Распространение продукта в виде rpm. Как?

[kit_D]

Здравствуйте,
Вопрос в следующем. Допустим мы придумали и реализовали некое приложение, изначально сориентированное для использования в Red Hat дистрибутива. Следующим шагом нам надо сгенерировать установочные rpm пакеты и выложить их для общего (или не совсем общего) использования. Так как нет возможности выложить кастомный пакет в существующий репозиторий Red Hat, то выкладывать rpm-ки вероятно придется именно в виде rpm-ок на кастомном сайте (не репозитории). Во всяком случае возможность создания своего репозитория не желательна.

Тут возникают следующие вопросы:
1) Вероятно надо создавать разные rpm-ки для разных архитектур, напр. i686, x86_64....
2) Надо ли собирать i686, x86_64 rpm-ки и входящие в них бинарные файлы именно на этих архитекторах (нативно)
3) Непонятно использование механизма зависимостей. Насколько я понимаю при сборке rpm зависимости прописываются в явном виде. Будут ли необходимые зависимости подтянуты инсталятором (как это делает yum, apt-get) из зарегистрированных в системе репозитариев в случае если сама rpm устанавливается не из репозитория, а с локального диска.

Есть и другие вопросы, но пока интересно было бы получить какие-то рекомендации по указанным выше.
Спасибо.

[Olej]

1) Вероятно надо создавать разные rpm-ки для разных архитектур, напр. i686, x86_64....
2) Надо ли собирать i686, x86_64 rpm-ки и входящие в них бинарные файлы именно на этих архитекторах (нативно)
3) Непонятно использование механизма зависимостей. Насколько я понимаю при сборке rpm зависимости прописываются в явном виде. Будут ли необходимые зависимости подтянуты инсталятором (как это делает yum, apt-get) из зарегистрированных в системе репозитариев в случае если сама rpm устанавливается не из репозитория, а с локального диска.

rpm-пакет вы делаете утилитой rpmbuild: пишите для своего пакета файл спецификации .spec и прогоняете его через rpmbuild.

Для других дистрибутивов (DEB-based, например) на сегодня есть уже дополнительные утилиты установки из .rpm, и наоборот: в RPM-based дистрибутивах из .deb.
Кроме того есть описанные детально методики создания .deb пакета из имеющегося .rpm.
Т.е. вопросы переносимости на ранних этапах вас не должны занимать - всё решаемо.

Если это бинарный .rpm (а не .src.rpm - пакет исходных кодов) вы строите, то, конечно, компиляция компонент на i686 и x86_64 должна делаться отдельно, и это будут 2 разных .rpm пакета.
Совсем не обязательно i686 собирать на i686, а x86_64 на x86_64 - вы можете опциями сборки собрать пакет кроссово x86_64 на i686 архитектуре и наоборот (некоторые ограничения будут накладывать вам модули ядра, если они есть в пакете: а). вы не можете их собрать в бинарный вид, а должны предусмотреть компиляцию-сборку из кодов уже в целевой системе при установке и б). эта сборка уже не может быть кроссовой - для этой сборки вовлекается всё дерево хэдеров актуального ядра и ещё файлы из /lib/modules).
Но гораздо проще получается (у меня так было) если "недостающую" архитектуру по-быстренькому (а это 15 минут делов) собрать виртуально в VirtualBox + там же провести нативную сборку пакета, ничего не настраивая под разные архитектуры.

Прописанные зависимости пакета, насколько я помню, ищутся и подтягиваются из зарегистрированных репозитариев.
Разницы между установкой .rpm из репозитария и локально из .rpm файла никакой нет (не считая того, что в локальном случае вам, чаще, предстоит устанавливать пакет без проверки сигнатуры GPG - опция --nogpgcheck у yum).
В спецификации сбоки .spec, которую вы составляете при сборке пакета, вы можете прописать любые скрипты прединсталляции и постинсталляции, т.е. предусмотреть что угодно, вплоть до скачивания каких-то исходных кодов по URL и их компиляции и сборки.

[Ali]

• Из одного спека можно генерировать много бинарных пакетов под разные архитектуры(посмотрите спек binutils или ядра). Под разные дистрибутивы надо писать разные спеки. Возможно генерировать целевые спеки cmake`ом и т.п. Возможны другие пути.
• На x86_64 можно собирать любой интел.
• Системы управления пакетами (yum, apt ...) будут обращаться в указанные в файлах конфигурации места. rpm -- нет.

Для разрешения проблем зависимостей, хедеров, чистоты сборки и т.п. давно придуманы инструменты разного уровня навороченности.
из простых:
https://fedorahosted.org/mock/
http://www.altlinux.org/Hasher

посложнее:
http://www.altlinux.org/Категория:Gear
http://fedoraproject.org/wiki/Koji
https://build.opensuse.

сложные:
http://wiki.rosalab.ru/ru/index.php/%D0 ... %D0%B0_ABF

[kit_D]

Во-первых, спасибо за ответы.
Подскажите пожалуйста, если вы имеете опыт с RHEL, используется ли там менеджер пакетов проверяющий зависимости и подтягивающий нужные rpm, как yum в Fedora или apt-get в Ubunta? Помню давным давно когда я работал в Red Hat 7.1/7.3, то все что там было это чистый rpm, т.е. зависимости надо было удовлетворять вручную.

[Olej]

Подскажите пожалуйста, если вы имеете опыт с RHEL, используется ли там менеджер пакетов проверяющий зависимости и подтягивающий нужные rpm, как yum в Fedora или apt-get в Ubunta? Помню давным давно когда я работал в Red Hat 7.1/7.3, то все что там было это чистый rpm, т.е. зависимости надо было удовлетворять вручную.

1. RHEL это та же Fedora ... но 3 релиза назад.

2. там именно всё тот же yum ... со множеством на выбор плагинов, появившихся за последнее время.

3. yum - это надстройка над rpm пакетной системой, нельзя их разрывать в рассмотрении, ... где-то я встречал в отношении yum название "метаменеджер"...

4. так же точно, как и apt-get, aptitude & synaptic - не являются менеджерами пакетной системы, а только метаменеджеры над deb пакетной системой.

[kit_D]

Ага, понял. Но все же интересно, подтянет ли yum зависимости из репозиториев при установке локальной rpm-ки?

[Olej]

Ага, понял. Но все же интересно, подтянет ли yum зависимости из репозиториев при установке локальной rpm-ки?

А вы попробуйте!
(прямо какой-то знакомый рекламный слоган нарисовался )

Возьмите любой пакет:

Код: Выделить всё

# yum localinstall --nogpgcheck xxx.rpm
...

Потом удалите .

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

[Olej]

Пару дней назад на сайте статей IBM Developer Works опубликовано начало (из 2-х статей) цикла статей:

Сборка RPM-пакетов для Mandriva: Часть №1. Основы сборки RPM
Сборка RPM-пакетов для Mandriva: Часть №2. Правила сборки

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

Здесь описаны минимально, но достаточно для начала, структура и написание файла спецификации пакета (SPEC-файл), вся остальная сборка пакета - это уже вопрос формальной техники.

[Olej]

Очень приличное руководство по сборке RPM пакетов: Packager's Guide

A guide to software packaging for Fedora 18
Edition 18.0.1

И ещё:
How to create a GNU Hello RPM package
How to create an RPM package

[alex65su]

В принципе, достаточно прочитать: "Цикл статей по сборке RPM и DEB пакетов", - от tigro.