Сложный инсталятор сложных вещей

puppet

. Уметь обновляться, т.е. не стирать и заливать заново, а как то мержиться по заданным правилам.

это просто надо создавать свое окружение и там основательно разворачить софт, а не гадить систему таким.

Скажи на чем написано? Что за платформа?

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

Связать их все между собой

Уметь обновляться

это в любом случае скриптуется руками. Неважно будет это свой велосипед, какой-нить puppet или пакетный менеджер.

А пакетные менеджеры всё что нужно (вызывать соотв. хуки при соотв. действиях) уже умеют.

vertexua

Распространяем в собранном виде, таргет системы это Centos и Ubuntu для сервера, остальное где угодно может работать. Рассчитано на штучное распространение а не на массовое.

это просто надо создавать свое окружение

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

При этом все компоненты могут находится как на одной машине так и на разных.

Сейчас идея сделать ПО след принцепу

Our_package
+ Server
  + ...
  + install.sh
+ DB
  + ...
  + install.sh
+ Web
  + ...
  + install.sh
+ install.sh

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

через пакетный менеджер нечто подобное можно сделать ?

PS. не удивлюсь если со временем к этому еще и UI захотят :)

через portage можно без проблем.

это все делается через стандартные установочные пакеты целевой платформы (rpm, deb, etc)

а вообще уже задолбали лезть со своими виндовыми замашками на линукс, учите матчасть, господа

Сейчас идея сделать ПО след принцепу

Честно говоря хреновая идея. Советую таки присмотрется к паппету как уже советовали, он по идее под эту задачу больше всего подходит если расширять нужно будет в будущем

Приложение отдается во вне, это «вне» закрыто за 7ю замками от внешнего интернета. Ни о каком удаленном администрировании и речи быть не может.

Мне нужно выполнить три этапа установки. 1. Развернуть сервер. 2. Развернуть БД. 3. Развернуть Web морду.

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

Я пытаюсь понять какие преимущества дадут мне пакетные менеджеры?

Пару преимуществ я все таки вижу:

1. Контроль версии со стороны пакетного менеджера, два раза установить одно и тоже не получится (я как раз задумался о том, что мне это нужно будет самому делать)

2. Вроде как менеджер позволит удалить пакет, но у нас пока вообще нет такого понятие как «удалить наш софт» :). Можно «выкатить новую версию», что пока равносильно заменить все старое. Что в принципе равносильно «удалить старое, установить новое»

С другой стороны я вижу одну проблему:

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

ну приемущества следующие:

• нативность для целевой системы
• отказ от своих велосипедов в пользу стандартного решения повышает стабильность
• стандартный механизм установки, обновления и удаления
• возможность нарезать твою систему на логические части и завернуть в отдельные пакеты (сервер, бд, web-морду или даже более мелкие, если имеет смысл)
• возможность сделать мета-пакеты, которые будут устанавливать более сложные конфигурации
• меньше негативного влияния на карму нехороших слов недовольных пользователей

и что ? Паппет абсолютно ортогонален к наличию интернетов в каком-либо виде. Это скорее более разумная замена скриптованию наркомании типа:

if [ $something ]; then
    rpm -Uvh <somepackage>
else
    rpm -Uvh <otherpackage>
fi

сравни с:

 package { "mypackage": 
        ensure => installed 
    }

можно конечно и без надстройки обойтись - например метапакетами как уже предложили. Главное не чистыми шелл-скриптами которые творят невесть что - за такое без крайней на то нужды стоит УБИВАТ :)

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

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

А с помощью чего можно сделать независимость от пакета ? Что бы не сопровождать два разных пакетных менеджера, а что то типа Cmake но для построения пакетов ?

Насчет таких средств не слышал (возможно гугл поможет), но если сделать rpm и deb - это покроет все самые популярные дистрибутивы. Причем, можно еще сэкономить. Правильно написанные rpm-пакеты без проблем конвертируются в deb программой alien.