Здравствуйте, 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>>>Неправильно. Этот вариант не учитывает политику дистрибутива и создает файлы в /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>Короче, нету, похоже, у тебя опыта одновременного администрирования по крайней мере пяти серверов.
Здравствуйте, Karamat, Вы писали:
K>Нужно создать дистрибутив программы для установки ее на linux. Есть какие нибудь пакеты, облегчающие задачу (типа Install shield)? Вообще, как это делается?
Здравствуйте, 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.
Нужно создать дистрибутив программы для установки ее на 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 должна быть.
А уж собрать пакет — это как говорится "Дело техники"..
Здравствуйте, 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 серверов — это не показатель крутизны и сложности, в мире юникс всё делает элементарно и большей частью автоматически.. (правда нужно немного для этого потрудится)
Оказалось что в 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..
а пакет для той системы под которую написана прога — это уже по своему усмотрению
)
