Использование deb-пакетов для дистрибъюции кода

[barbuza]

при использовании git / mercurial мы тоже защищены от «проблемы с .svn папками». это не проблема, а кривые руки.

[krestjaninoff]

Речь не том, что лучше: SVN или GIT/Mercurial. Я лишь хочу сказать, что использование пакетов отчасти уменьшает риски, связанные с кривыми руками.

[mou]

Ant автоматом делает исключение служебных файлов VCS. Опция exclude лишняя.

[RZimin]

Отлично! Надо будет попробовать, вот только зачем .ini :(

[krestjaninoff]

Спасибо. Ссылку добавил. По части изменения прав — тоже мой недочёт, действительно логичней было бы поместить их установку в ant'овский конфиг.

[cabeza]

Мы раскладываем ключи дежурных из отдела мониторинга вместе с конфигами sudo как раз пакуя их в rpm-ку.
К сожалению, это всё от лени плотно взяться за cfengine/puppet/etc…

[Maklaut]

Основной сценарий сборки содержится в файле packege.xml

[eeexception]

Супер) То, что доктор прописал, особенно для java проектов)
А тоже самое для rpm-based дистрибутивов сделать можно?

[krestjaninoff]

Думаю, да.

[Deepwalker]

Одного не понял — зачем тут ant? Ну то есть ничего против не имею конечно, но обычный Makefile, который debian/rules вполне достаточен, а главное для редактирования приятнее: )

Потом — не вижу вызовов debhelper утилит — все, связанное с питоном к примеру, будете руками делать? Все папки пустые руками? Зря в общем изобретаете, сугубо на мой взгляд: )

Если не прав — пожалуйста укажите на ошибки, может быть я просто недопонял статью.

[krestjaninoff]

Ant мне исторически ближе, а с debhelper сталкиваться не приходилось. Возможно их использование здесь действительно было бы удачней.

[Deepwalker]

В debhelper стандартный набор утилит, которые по списку создадут все директории, скопируют файлы по списку, завернут в deb автоматически по debian/control.

[eeexception]

Если не ошибаюсь, то в текущем вариант deb пакет можно собрать и из под windows машины… А про вариант с debhelper можно подробнее услышать?

[Deepwalker]

Можно поподробнее почитать: )

А про сборку пакетов на win-машине, ну кому оно надо? У нас в корне проекта лежит директория debian со стандартным debian/rules, с помощью которой все собирается обычным fakeroot debian/rules binary. Так вот — нет linux на машине разработчика? Соберите пакеты на build-сервере, и не надо заморачиваться на предмет «а вдруг кому то захочется родить ежика против шерсти??».

[eeexception]

А если собирать и rpm, и deb одновременно?) Для каждого варианта держать свой дистрибутив?)

[Deepwalker]

Согласитесь, rpm под debian собрать это элементарно. Наверное что то вроде aptitude install rpm понадобится.

[eeexception]

Можно) Но не очень нравится вариант с установкой всего необходимого) С антом может путь и не совсем true, зато более изящней.

[Deepwalker]

Ничего изящного в нем нет, потому что те утилиты, что существуют для создания пакетов в дистрибутивах много лет уже затачиваются под эти цели. И все что в них есть, вы будете в ant делать руками.

Если вам хочется «красиво», то оно таковым будет до более менее комплексной конфигурации, а потом начнется лес подпорок.

Зачастую в проекте собираются десятки пакетов, с помощью debhelper это делается легко, с помощью любой другой системы вы будете повторять уже существующее.

Я не понимаю, чем плох make в данном случае. Make очень изящен, гораздо изящнее многословного xml.

[eeexception]

Все дело в привычке) И опять же для зоопарка машин разработчиков, когда у каждого своя операционная система от Windows, различных Linux дистрибутивов до Mac, ant гарантирует одинаковость сборки всего продукта на любой из приведенных систем.

[Deepwalker]

Сборка != пакетирование под debian.

[CheatEx]

Не совсем уловил как решается проблема наличия dpkg-deb и что мешает аналогично решить проблему с dh_*?

[CheatEx]

www.debian.org/doc/debian-policy — кури — не хочу!

[hydralien]

Использовали схему с пакетами для релизов своих проектов, но отказались в пользу тагированного деплоймента из меркуриала. Потому как второе было быстрее в случае небольших срочных патчей и легче разделялось на sandbox/prod deployment. Но вообще схема с пакетами во многих случаях хороша, да — особенно в плане автоматических зависимостей.

[mocksoul]

Йех, разработчики на интерпретируемых языках ну совсем обленились =).
Имхо, отсутствие системы билдинга даже helloworld.(py|php|pl|whatever) проекта — глупость, которая замедляет и обостряет production-развертывание.

[BorisPlus]

И мне Ant как-то роднее. Переработал. Пригодилось. Спасибо!