Нужно создать дистрибутив программы для установки ее на linux. Есть какие нибудь пакеты, облегчающие задачу (типа Install shield)? Вообще, как это делается?
Здравствуйте, Karamat, Вы писали:
K>Нужно создать дистрибутив программы для установки ее на linux. Есть какие нибудь пакеты, облегчающие задачу (типа Install shield)? Вообще, как это делается?
Здравствуйте, Karamat, Вы писали:
K>Нужно создать дистрибутив программы для установки ее на linux. Есть какие нибудь пакеты, облегчающие задачу (типа Install shield)? Вообще, как это делается?
Здравствуйте, Karamat, Вы писали:
K>Нужно создать дистрибутив программы для установки ее на linux. Есть какие нибудь пакеты, облегчающие задачу (типа Install shield)? Вообще, как это делается?
Самый правильный вариант — исходники с makefile, в котором есть make install .
Ну и, конечно, *.deb и *.rpm
Здравствуйте, DOOM, Вы писали:
DOO>Самый правильный вариант — исходники с makefile, в котором есть make install .
Неправильно. Этот вариант не учитывает политику дистрибутива и создает файлы в /bin, /sbin, /usr, /opt или еще где, которые не попадают под действие пакетного менеджера.
Исходники должны быть собирабельны непосредственно через rpmbuild/debmake или иметь соответствующие цели в Makefile
DOO>Ну и, конечно, *.deb и *.rpm
Здравствуйте, m.a.g., Вы писали:
MAG>Здравствуйте, DOOM, Вы писали:
DOO>>Самый правильный вариант — исходники с makefile, в котором есть make install .
MAG>Неправильно. Этот вариант не учитывает политику дистрибутива и создает файлы в /bin, /sbin, /usr, /opt или еще где, которые не попадают под действие пакетного менеджера.
ну не скажи, это (с Makefile), ИМХО, более правильный вариант, и не привязан к конкретному дистрибутиву.
Другое дело на сколько грамотно он выполнен?.. Все пути должны настраиваться через configure, и цель make deinstall должна быть.
А уж собрать пакет — это как говорится "Дело техники"..
Здравствуйте, butcher, Вы писали:
MAG>>Неправильно. Этот вариант не учитывает политику дистрибутива и создает файлы в /bin, /sbin, /usr, /opt или еще где, которые не попадают под действие пакетного менеджера.
B>ну не скажи, это (с Makefile), ИМХО, более правильный вариант, и не привязан к конкретному дистрибутиву.
Именно поэтому он абсолютно неграмотен.
B>Другое дело на сколько грамотно он выполнен?.. Все пути должны настраиваться через configure, и цель make deinstall должна быть. А уж собрать пакет — это как говорится "Дело техники"..
Поясняю. Что будет, если ты собираешь свой MTA и хочешь его поставить вместо стандартного debian'овского?
1. Ты должен будешь руками разгребать /var/dpkg/alternatives
2. Ты должен будешь ставить все пакеты, завязанные на MTA, без зависимостей — это с весьма большой вероятностью приведет к багам
3. Ты должен будешь проделывать операцию сборки/установки на каждой машине, куда тебе его надо ставить
Неужели все это не перевесит единовременного создания debian/rules или package.spec? Сомневаюсь. Тем более, что их уже можно взять из существующих пакетов и поправить.
Короче, нету, похоже, у тебя опыта одновременного администрирования по крайней мере пяти серверов.
Здравствуйте, m.a.g., Вы писали:
MAG>Здравствуйте, butcher, Вы писали:
MAG>Именно поэтому он абсолютно неграмотен.
Ну если мы уже переходим на личности, то наверно у тебя мало опыта работы с исходниками..
B>>Другое дело на сколько грамотно он выполнен?.. Все пути должны настраиваться через configure, и цель make deinstall должна быть. А уж собрать пакет — это как говорится "Дело техники"..
MAG>Поясняю. Что будет, если ты собираешь свой MTA и хочешь его поставить вместо стандартного debian'овского?
а для чего? Не ужели в линуксе нельзя поставить МТА рядом с уже существующим не трогая системного?
Как это делается в FreeBSD:
Если у тебя есть желаение поставить другой МТА вместо стандартного, ставишь его в /usr/local/[..]
правишь необходимые файлы в /etc и всё, киляешь текущего, запускаешь нового
Если ты хочешь пропатчить текущий, cvs(up) исходников и make install (элементарно)
Если ты не хочешь возится с конфигурацией скриптов — есть порты и пакаджи, за тебя это уже сделали
MAG>Неужели все это не перевесит единовременного создания debian/rules или package.spec? Сомневаюсь. Тем более, что их уже можно взять из существующих пакетов и поправить.
Одно другому не мешает, ИМХО, в стандартном виде (tar.gz) пакет должен существовать, для того чтобы быть хоть в какой-то мере переносимым, а создание пакетов — это дело, ИМХО, в большей степени создателя дистрибутива ОС, а не дистрибутива программы.
MAG>Короче, нету, похоже, у тебя опыта одновременного администрирования по крайней мере пяти серверов.
Может потому, что я выбираю не линукс, а FreeBSD и у меня не возникает таких сложностей?
PS. я думаю дальше не стоит продолжать этот флейм, а 5 серверов — это не показатель крутизны и сложности, в мире юникс всё делает элементарно и большей частью автоматически.. (правда нужно немного для этого потрудится)
Здравствуйте, m.a.g., Вы писали:
MAG>Здравствуйте, butcher, Вы писали:
MAG>>>Неправильно. Этот вариант не учитывает политику дистрибутива и создает файлы в /bin, /sbin, /usr, /opt или еще где, которые не попадают под действие пакетного менеджера.
B>>ну не скажи, это (с Makefile), ИМХО, более правильный вариант, и не привязан к конкретному дистрибутиву.
MAG>Именно поэтому он абсолютно неграмотен.
И к какому дистрибутиву ты предлагаешь привязываться.
B>>Другое дело на сколько грамотно он выполнен?.. Все пути должны настраиваться через configure, и цель make deinstall должна быть. А уж собрать пакет — это как говорится "Дело техники"..
MAG>Поясняю. Что будет, если ты собираешь свой MTA и хочешь его поставить вместо стандартного debian'овского?
MAG>1. Ты должен будешь руками разгребать /var/dpkg/alternatives MAG>2. Ты должен будешь ставить все пакеты, завязанные на MTA, без зависимостей — это с весьма большой вероятностью приведет к багам MAG>3. Ты должен будешь проделывать операцию сборки/установки на каждой машине, куда тебе его надо ставить
Странно, а у меня на машине нет /var/dpkg/alternatives. Я что, ущербный?
Лично я ставлю программы в отдельные каталоги в /usr/local, а потом делаю на них ссылки из /usr/local/bin.
Разные версии одной и той же программы ставятся в разные каталоги. Можно потестить, перед тем, как начинать пользоваться новой версией; можно легко откатиться; если очень надо, можно использовать конкретную версию; понятно, кого стирать
Если машины более менее одинаковые достаточно собрать один раз и скопировать на все.
MAG>Неужели все это не перевесит единовременного создания debian/rules или package.spec? Сомневаюсь. Тем более, что их уже можно взять из существующих пакетов и поправить.
MAG>Короче, нету, похоже, у тебя опыта одновременного администрирования по крайней мере пяти серверов.
Оказалось что в KDevelop есть эта фича. Но у меня почему-то не работает:
Projects -> Make distribution -> Source-tgz
Projects -> Make distribution -> Build RPM Package — "You need generate source dist first.."
Projects -> Make distribution -> Configure RPM Package -> Buid — "You need generate source dist first.."
В чем проблема — вроде архив создался (он появляется в дериктории с проектом)?
Здравствуйте, butcher, Вы писали:
B>Как это делается в FreeBSD: B>Если у тебя есть желаение поставить другой МТА вместо стандартного, ставишь его в /usr/local/[..] B>правишь необходимые файлы в /etc и всё, киляешь текущего, запускаешь нового
Вот-вот. Правишь файлы, киляешь текущего... Зачем? Все уже придумано до нас.
Здравствуйте, butcher, Вы писали:
MAG>>Именно поэтому он абсолютно неграмотен. B>Ну если мы уже переходим на личности, то наверно у тебя мало опыта работы с исходниками..
Ну у меня есть опыт и с тем и с тем. И я согласен с MAG.
B>>>Другое дело на сколько грамотно он выполнен?.. Все пути должны настраиваться через configure, и цель make deinstall должна быть. А уж собрать пакет — это как говорится "Дело техники".. MAG>>Поясняю. Что будет, если ты собираешь свой MTA и хочешь его поставить вместо стандартного debian'овского? B>а для чего? Не ужели в линуксе нельзя поставить МТА рядом с уже существующим не трогая системного?
Можно. Вопрос не в том, чтобы просто поставить. Вопрос в том, чтобы иметь возможность
поставить и в отдельный каталог, и в стандартный. Кроме того, обеспечить как работу инсталлятора самого по себе (в тестовых целях в какой-нибудь /usr/local/tmp222),
так и на постоянное место. А для этого и нужна адекватная тому инфраструктура.
Например, такую инфраструктуру — в виде Makefile — делает GNU automake, и я рекомендую смотреть именно на него в первую очередь (когда нет причин использовать что-то другое).
B>Как это делается в FreeBSD:
У меня тоже в основном FreeBSD. Но ты рассказываешь про установку в /usr/local/нечто,
которая не зависит ни от FreeBSD ни от вообще free unices. Так можно ставить куда угодно
где вообще есть файловая система. Но если дистрибутив будет состоять из сплошных
/usr/${zuka}/, а остальное будет линками на него — это не будет нормальный вариант
дистрибутива.
B>Если у тебя есть желаение поставить другой МТА вместо стандартного, ставишь его в /usr/local/[..] B>правишь необходимые файлы в /etc и всё, киляешь текущего, запускаешь нового B>Если ты хочешь пропатчить текущий, cvs(up) исходников и make install (элементарно) B>Если ты не хочешь возится с конфигурацией скриптов — есть порты и пакаджи, за тебя это уже сделали
"Всё сделали" — это сказано крепко, но неадекватно. Почитай cvs-ports, о том, как регулярно выносят тот или иной порт за испорченный pkg-plist или молчаливое затирание чужих данных. О том, что ты не можешь сделать make package без make install (что умеет, например, OpenBSD, где фряшную систему портов довели до ума — в этом смысле). Ни на какие
мысли не наводит? Порты — не критерий, критерий — там, где пакетный менеджер хоть сколько-то похож на человеческий, а это rpm или deb, и который умеет такие простые вещи,
как собирать пакеты ставя их во временный каталог вместо общего корня.
MAG>>Неужели все это не перевесит единовременного создания debian/rules или package.spec? Сомневаюсь. Тем более, что их уже можно взять из существующих пакетов и поправить. B>Одно другому не мешает, ИМХО, в стандартном виде (tar.gz) пакет должен существовать, для того чтобы быть хоть в какой-то мере переносимым, а создание пакетов — это дело, ИМХО, в большей степени создателя дистрибутива ОС, а не дистрибутива программы.
Да, но надо им помогать. Если у тебя Makefile сгенерирован automake, он пригоден одновременно и для установки простым make install по указанному prefix, и для управления этим через rpmbuild или аналогичное средство deb, и через фряшную систему с bsd.port.mk.
А если ты будешь писать нечто своё самопальное, то в лучшем случае на него наложат патч
размером больше чем твой исходник, а в худшем — выбросят нафиг со словами "нехер бодаться с этим вторичным продуктом, когда есть более вменяемые альтернативы".
MAG>>Короче, нету, похоже, у тебя опыта одновременного администрирования по крайней мере пяти серверов. B>Может потому, что я выбираю не линукс, а FreeBSD и у меня не возникает таких сложностей?
А у меня ~40 систем под FreeBSD. И я согласен с MAG. Более того, под Linux c RPM
проблем меньше — это я тебе говорю как старый BSD'шник и известный в соответствующих
кругах всего exUSSR линуксоненавистник.
B>PS. я думаю дальше не стоит продолжать этот флейм, а 5 серверов — это не показатель крутизны и сложности, в мире юникс всё делает элементарно и большей частью автоматически.. (правда нужно немного для этого потрудится)
Ну так зачем много трудиться, когда достаточно Makefile.am на десять тривиальных строчек? )))
P.S. Не хочешь automake — есть Imake, есть масса других средств. Просто это — достаточно
удобное и стандартное, чтобы его рассматривать как вариант по умолчанию.
Ну я же просил не разводить флейм )
N>Ну у меня есть опыт и с тем и с тем. И я согласен с MAG.
я не против его точки зрения, я всего лишь говорю что дистрибутив должен существовать в формате tar.gz
N>Можно. Вопрос не в том, чтобы просто поставить. Вопрос в том, чтобы иметь возможность N>поставить и в отдельный каталог, и в стандартный. Кроме того, обеспечить как работу инсталлятора самого по себе (в тестовых целях в какой-нибудь /usr/local/tmp222), N>так и на постоянное место. А для этого и нужна адекватная тому инфраструктура. N>Например, такую инфраструктуру — в виде Makefile — делает GNU automake, и я рекомендую смотреть именно на него в первую очередь (когда нет причин использовать что-то другое).
само собой, не руками же его стряпать (хотя и такие встречаются
N>У меня тоже в основном FreeBSD. Но ты рассказываешь про установку в /usr/local/нечто, N>которая не зависит ни от FreeBSD ни от вообще free unices. Так можно ставить куда угодно N>где вообще есть файловая система. Но если дистрибутив будет состоять из сплошных N>/usr/${zuka}/, а остальное будет линками на него — это не будет нормальный вариант N>дистрибутива.
про линке это не я предлагал
N>"Всё сделали" — это сказано крепко, но неадекватно. Почитай cvs-ports, о том, как регулярно выносят тот или иной порт за испорченный pkg-plist или молчаливое затирание чужих данных. О том, что ты не можешь сделать make package без make install (что умеет, например, OpenBSD, где фряшную систему портов довели до ума — в этом смысле). Ни на какие N>мысли не наводит? Порты — не критерий, критерий — там, где пакетный менеджер хоть сколько-то похож на человеческий, а это rpm или deb, и который умеет такие простые вещи, N>как собирать пакеты ставя их во временный каталог вместо общего корня.
N>А у меня ~40 систем под FreeBSD. И я согласен с MAG. Более того, под Linux c RPM N>проблем меньше — это я тебе говорю как старый BSD'шник и известный в соответствующих N>кругах всего exUSSR линуксоненавистник.
вот такого флейм я и боялся, я не противник линукса, мне просто нравится БСД, если кому-то не нравится, сидите в своём линухе
B>>PS. я думаю дальше не стоит продолжать этот флейм, а 5 серверов — это не показатель крутизны и сложности, в мире юникс всё делает элементарно и большей частью автоматически.. (правда нужно немного для этого потрудится)
N>Ну так зачем много трудиться, когда достаточно Makefile.am на десять тривиальных строчек? N>))))
Я всего лишь хотел указать на то, что обязательно необходим вариант с Makefile..
а пакет для той системы под которую написана прога — это уже по своему усмотрению
Здравствуйте, butcher, Вы писали:
B>Ну я же просил не разводить флейм )
А где ты увидел флейм?? Я наоборот доказываю непредвзятость своей позиции. )
N>>Ну у меня есть опыт и с тем и с тем. И я согласен с MAG. B>я не против его точки зрения, я всего лишь говорю что дистрибутив должен существовать в формате tar.gz
Это да. Но что в этом тарболле — существенно не менее, чем его существование)
И если ты дашь максимум средств для сборки и установки во всех основных применяемых сейчас
технологиях (а это и установка вручную, и установка под пакетными менеджерами), тебе скажут спасибо
значительно вероятнее, чем если ты такого не дашь.
N>>А у меня ~40 систем под FreeBSD. И я согласен с MAG. Более того, под Linux c RPM N>>проблем меньше — это я тебе говорю как старый BSD'шник и известный в соответствующих N>>кругах всего exUSSR линуксоненавистник. B>) B>вот такого флейм я и боялся, я не противник линукса, мне просто нравится БСД, если кому-то не нравится, сидите в своём линухе
Ну и мне FreeBSD больше нравится — на порядок.
B>>>PS. я думаю дальше не стоит продолжать этот флейм, а 5 серверов — это не показатель крутизны и сложности, в мире юникс всё делает элементарно и большей частью автоматически.. (правда нужно немного для этого потрудится)
N>>Ну так зачем много трудиться, когда достаточно Makefile.am на десять тривиальных строчек? N>>))))
B>Я всего лишь хотел указать на то, что обязательно необходим вариант с Makefile.. B>а пакет для той системы под которую написана прога — это уже по своему усмотрению
Вот-вот. А я говорю, что чтобы твоя программа была известна за пределами "узкого круга ограниченных людей" — надо ориентироваться и на линуксы, а это сейчас практически 100% означает — использовать automake или иным образом обеспечивать минимум проблем при сборке через rpmbuild.
.
