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

[Olej]

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

Достаточно ли? - вопрос сложный...

Во-первых, потому, что написано это в начале 2007 года, а практика показывает, что со временем накапливаются отличия в мелочах, и когда объём этих мелочей переваливает критический, следовать любым устаревшим описаниям становится невозможно (легче самому "с нуля" разобраться).

Во-вторых, потому, там даже в первой, вводной статье цикла (Сборка пакетов. Глава 1. RPM. Часть 1. Какие RPM-пакеты бывают, и где их искать.) есть часть достаточно спорных, вызывающих сомнение утверждений.

Хотя публикация интересная ... я лично проработаю её до конца.

[alex65su]

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

Достаточно ли? - вопрос сложный...

Во-первых, потому, что написано это в начале 2007 года, а практика показывает, что со временем накапливаются отличия в мелочах, и когда объём этих мелочей переваливает критический, следовать любым устаревшим описаниям становится невозможно (легче самому "с нуля" разобраться).

imho, Для человека, который никогда этим не занимался, чтобы понять основные принципы сборки RPM-пакетов и для самостоятельной упаковки ПО без каких-либо сложных трюков - вполне достаточно (даже с учетом древности публикации). Вполне естественно, что объём этого цикла статей не позволяет вместить полное описание абсолютно всех внутренних макросов RPM, для этого есть сопроводительная справочная документация. Поэтому, если упаковка ПО в RPM-пакет требует учёта каких-то тонких моментов, то придётся либо читать самую свежую сопроводительную документацию, либо "ковырять" файлы макроопределений rpm для конкретной инсталляции (кстати, именно тут накапливаются и скрываются самые "подлые" мелочи, которые, к тому же, ни в какой документации, как правило, не описываются), либо, в очень редких случаях когда нужно что-то уж совсем странное, и читать, и "ковырять".

Во-вторых, потому, там даже в первой, вводной статье цикла (Сборка пакетов. Глава 1. RPM. Часть 1. Какие RPM-пакеты бывают, и где их искать.) есть часть достаточно спорных, вызывающих сомнение утверждений.

Например?

[Olej]

Во-вторых, потому, там даже в первой, вводной статье цикла (Сборка пакетов. Глава 1. RPM. Часть 1. Какие RPM-пакеты бывают, и где их искать.) есть часть достаточно спорных, вызывающих сомнение утверждений.

Например?

Например?

Например то, что вряд ли нужно было описывать подробно отличия RPM пакетов и технологии сборки "других" дистрибутивов, таких как Mandriva, SUSE, ALT - только сказать, что они совпадают только по названию. И акцентироваться на том:
- что .rpm таких дистрибутивов не годятся для использования в Fedora, не представляют интереса, нельзя устанавливать и не нужно смотреть в их сторону;
- что текущее описание покрывает семейство дистрибутивов Fedora, RedHat, CentOS и, наверное, Scientific и, возможно, Oracle Linux.

Например то, и это важнее, что утверждается категорическое мнение, что если из исходников собирать проект, то нужно а). сначала собрать из исходников RPM, а затем б). устанавливать из RPM. Это хорошая технология, но только в некоторых случаях!:

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

2. сборка RPM - процесс посложнее часто типовой сборки из исходников, и не профессионалу что то, что другое часто не под силу, и ему нужно не советовать так делать, а отговаривать

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

[alex65su]

Например то, что вряд ли нужно было описывать подробно отличия RPM пакетов и технологии сборки "других" дистрибутивов, таких как Mandriva, SUSE, ALT ... ... ...

Бывают ситуации, когда есть RPM-пакет для, например, SUSE, а для RedHat-ообразия его просто нету. При этом есть исходный RPM-пакет и его нужно пересобрать под RedHat-ообразие...

Например то, и это важнее, что утверждается категорическое мнение, что если из исходников собирать проект, то нужно а). сначала собрать из исходников RPM, а затем б). устанавливать из RPM. Это хорошая технология, но только в некоторых случаях!:

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

2. сборка RPM - процесс посложнее часто типовой сборки из исходников, и не профессионалу что то, что другое часто не под силу, и ему нужно не советовать так делать, а отговаривать

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

Вы тоже утверждаете категорическое мнение

Тем не менее... попытаюсь обосновать категоричность мнения автора цикла статей tigro:

1. Один программист-разработчик (или какой-то любознательный экспериментатор) устанавливает свежее ПО на один, два, реже три компьютера, и "живёт" это ПО в этих компьютерах ровно до тех пор пока к нему есть интерес. После чего это ПО убирается (при свежей памяти, что и куда было установлено), чтобы не захламлять систему. В этом случае я с Вами полностью согласен!

А вот в случае необходимости установки ПО для длительной эксплуатации на несколько компьютеров, и, при этом, кроме этого ПО необходимо доустанавливать еще что-то нужное, то возня со сборкой RPM-пакетов окупиться потом более лёгким администрированием этих систем, потому что через месяц-другой помнить, что куда поставили и все зависимости будет только rpm

2. А если непрофессионал желает стать профессионалом?

3. Для определённой категории ПО существует понятие типовой сборки, и сборки под конкретный функционал требуемый заказчиком. Asterisk и FreeSWITCH - как раз из этой категории (+аппаратный зоопарк). Однако, и в таком случае, для облегчения последующей эксплуатации, сборка RPM-пакета для конкретной системы может себя оправдать, особенно если учесть, что исходный SRPM-пакет, при этом, будет содержать в себе все требуемые для этой системы исходники, заплаты и правила сборки ПО.

[Olej]

Например то, что вряд ли нужно было описывать подробно отличия RPM пакетов и технологии сборки "других" дистрибутивов, таких как Mandriva, SUSE, ALT ... ... ...

Бывают ситуации, когда есть RPM-пакет для, например, SUSE, а для RedHat-ообразия его просто нету. При этом есть исходный RPM-пакет и его нужно пересобрать под RedHat-ообразие...

Практически всё, собираемое в пакеты (в любой пакетной системе) - это открытые свободные проекты. В таком случае гораздо целесообразнее:
- отправиться на домашнюю страницу проекта, скачать оттуда исходники наипоследнейшей версии пакета;
- а из него уже собирать пакет, в частности RPM.
Это куда разумнее, чем перепаковывать пакет из того же SUSE, где сама версия реализуемого проекта далеко не самая свежая (многие проекты обновляются весьма часто, хотя есть и исключения - SMB 4.0, очередное релиз, вон готовили 10 лет).

Совсем другое дело - закрытые проприетарные продукты (даже для свободного обращения).
Из самых известных (и безальтернативных) - это: Oracle (Sun) JDK, Virtual Box, NVIDIA драйвера + CUDA SDK, Skype, ...
Здесь совсем другое дело... Но здесь, как мне кажется, смешны потуги дистрибьюторов запаковывать "кота в мешке" в свои пакеты - такие вещи должны ставиться из оригинальных инсталляций от их владельцев.

А вот в случае необходимости установки ПО для длительной эксплуатации на несколько компьютеров, и, при этом, кроме этого ПО необходимо доустанавливать еще что-то нужное, то возня со сборкой RPM-пакетов окупиться потом более лёгким администрированием этих систем, потому что через месяц-другой помнить, что куда поставили и все зависимости будет только rpm

Я не говорил ничего про тиражную установку. Как только возникает задача тиражировать установку на сколько-то-там экземпляров компьютеров - здесь нужно готовить пакет для установки.

3. Для определённой категории ПО существует понятие типовой сборки, и сборки под конкретный функционал требуемый заказчиком. Asterisk и FreeSWITCH - как раз из этой категории (+аппаратный зоопарк). Однако, и в таком случае, для облегчения последующей эксплуатации, сборка RPM-пакета для конкретной системы может себя оправдать, особенно если учесть, что исходный SRPM-пакет, при этом, будет содержать в себе все требуемые для этой системы исходники, заплаты и правила сборки ПО.

Ну так нет же таких (сборок)!
Не оправдало

[Olej]

то возня со сборкой RPM-пакетов окупиться потом более лёгким администрированием этих систем, потому что через месяц-другой помнить, что куда поставили и все зависимости будет только rpm

Кроме того, для объективности, и особенно для вновь подключающихся пользователей, нужно говорить (чтоб не вводить в заблуждение) такие, например, вещи:

1. есть дистрибутивы, в которых нет (не было, и никогда не будет ) пакетной инсталляции, и в которых установка в большей или меньшей мере идёт из исходных кодов. Показательные примеры: Slackware & Gentoo.
И они неплохо себе живут.

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

3. существуют средства от сторонних разработчиков для учёта и контроля инсталляций из исходных кодов, например stow и xstow, позволяющие в большой мере делать то же, что и пакетная система.

4. более того, в последние годы среди разработчиков проектов стало широко распространено (то ли культура разработки повысилась, то ли модно стало) добавлять в make цель деисталляции, как мы ставим проект:

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

# make install

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

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

# make uninstall

5. и последнее ... в разных ОС в разное время использовались (опробывались) разные пакетные системы.
И практика показала, что все они порождают со временем проблемы.
И что полноценная система инсталляций должна бы использовать пакеты исходных кодов с отслеживанием зависимостей в иерархии проектов. И такая пакетная система существует: pkgsrc из NetBSD. И в разных ОС поочерёдно отказываются от собственных систем инсталляций, и переходят на pkgsrc: Solaris, QNX, Minix ... не говоря уже о самих разнообразных BSD. Существует порт pkgsrc для Linux ... только вряд ли кто во враждующем сообществе дистрибутивов решится на его основное использование.

[alex65su]

Практически всё, собираемое в пакеты (в любой пакетной системе) - это открытые свободные проекты. В таком случае гораздо целесообразнее:
- отправиться на домашнюю страницу проекта, скачать оттуда исходники наипоследнейшей версии пакета;
- а из него уже собирать пакет, в частности RPM.
Это куда разумнее, чем перепаковывать пакет из того же SUSE, где сама версия реализуемого проекта далеко не самая свежая (многие проекты обновляются весьма часто, хотя есть и исключения - SMB 4.0, очередное релиз, вон готовили 10 лет).

Случаи бывают самые разные, и не всегда может быть нужна самая последняя версия ПО...

Совсем другое дело - закрытые проприетарные продукты ...

Это, вообще, отдельная тема.

3. Для определённой категории ПО существует понятие типовой сборки, и сборки под конкретный функционал требуемый заказчиком. Asterisk и FreeSWITCH - как раз из этой категории (+аппаратный зоопарк). Однако, и в таком случае, для облегчения последующей эксплуатации, сборка RPM-пакета для конкретной системы может себя оправдать, особенно если учесть, что исходный SRPM-пакет, при этом, будет содержать в себе все требуемые для этой системы исходники, заплаты и правила сборки ПО.

Ну так нет же таких (сборок)!
Не оправдало

Раз уж зашла речь про Asterisk и FreeSWITCH, то вот на этом примере и представим, что Вам необходимо инсталлировать для ваших заказчиков на N узлов эти системы, а потом их сопровождать. Можно, конечно, записать в какой-то свой блокнот/журнал/etc... что и как для какого узла собиралось, а можно для каждого узла собрать свои уникальные RPM/SRPM-пакеты и иметь их под рукой. В последствии, при крахе какой-либо из сопровождаемых систем, повторное развёртывание делается из готового бинарного RPM, а SRPM служит исчерпывающей шпаргалкой на тему сборки. Если, при этом, есть архивные копии настроек, то восстановление работоспособности рухнувшей системы займет гораздо меньше времени, чем повторная сборка из исходников. Плюс, для выполнения такой процедуры не нужен специалист, который досконально знает процесс сборки ПО из исходников.

Добавлю: у RPM есть еще одна приятная для администрирования особенность: он позволяет осуществить верификацию установленного ПО. Это весьма полезная вещь в разных нештатных ситуациях!

[alex65su]

Кроме того, для объективности ... : 1, 2, 3, 4, 5

Вообще, все началось с вопроса: "Распространение продукта в виде rpm. Как?"

imho, мы, похоже, как-то начали отклоняться от этого вопроса совсем в другие дебри

Я прекращаю спорить.

[Olej]

Кроме того, для объективности ... : 1, 2, 3, 4, 5

imho, мы, похоже, как-то начали отклоняться от этого вопроса совсем в другие дебри

Я прекращаю спорить.

Это писалось не для спора. Интересно было мнение вообще по применению пакетных систем (особенно потому, что в статьях затронуты две очень разные пакетные системы .rpm и .deb).