Как стать автором
Обновить

Комментарии 26

при использовании git / mercurial мы тоже защищены от «проблемы с .svn папками». это не проблема, а кривые руки.
Речь не том, что лучше: SVN или GIT/Mercurial. Я лишь хочу сказать, что использование пакетов отчасти уменьшает риски, связанные с кривыми руками.
Ant автоматом делает исключение служебных файлов VCS. Опция exclude лишняя.
Отлично! Надо будет попробовать, вот только зачем .ini :(
НЛО прилетело и опубликовало эту надпись здесь
Спасибо. Ссылку добавил. По части изменения прав — тоже мой недочёт, действительно логичней было бы поместить их установку в ant'овский конфиг.
Мы раскладываем ключи дежурных из отдела мониторинга вместе с конфигами sudo как раз пакуя их в rpm-ку.
К сожалению, это всё от лени плотно взяться за cfengine/puppet/etc…
Основной сценарий сборки содержится в файле packege.xml
Супер) То, что доктор прописал, особенно для java проектов)
А тоже самое для rpm-based дистрибутивов сделать можно?
Думаю, да.
Одного не понял — зачем тут ant? Ну то есть ничего против не имею конечно, но обычный Makefile, который debian/rules вполне достаточен, а главное для редактирования приятнее: )

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

Если не прав — пожалуйста укажите на ошибки, может быть я просто недопонял статью.
Ant мне исторически ближе, а с debhelper сталкиваться не приходилось. Возможно их использование здесь действительно было бы удачней.
В debhelper стандартный набор утилит, которые по списку создадут все директории, скопируют файлы по списку, завернут в deb автоматически по debian/control.
Если не ошибаюсь, то в текущем вариант deb пакет можно собрать и из под windows машины… А про вариант с debhelper можно подробнее услышать?
Можно поподробнее почитать: )

А про сборку пакетов на win-машине, ну кому оно надо? У нас в корне проекта лежит директория debian со стандартным debian/rules, с помощью которой все собирается обычным fakeroot debian/rules binary. Так вот — нет linux на машине разработчика? Соберите пакеты на build-сервере, и не надо заморачиваться на предмет «а вдруг кому то захочется родить ежика против шерсти??».
А если собирать и rpm, и deb одновременно?) Для каждого варианта держать свой дистрибутив?)
Согласитесь, rpm под debian собрать это элементарно. Наверное что то вроде aptitude install rpm понадобится.
Можно) Но не очень нравится вариант с установкой всего необходимого) С антом может путь и не совсем true, зато более изящней.
Ничего изящного в нем нет, потому что те утилиты, что существуют для создания пакетов в дистрибутивах много лет уже затачиваются под эти цели. И все что в них есть, вы будете в ant делать руками.

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

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

Я не понимаю, чем плох make в данном случае. Make очень изящен, гораздо изящнее многословного xml.
Все дело в привычке) И опять же для зоопарка машин разработчиков, когда у каждого своя операционная система от Windows, различных Linux дистрибутивов до Mac, ant гарантирует одинаковость сборки всего продукта на любой из приведенных систем.
Сборка != пакетирование под debian.
Не совсем уловил как решается проблема наличия dpkg-deb и что мешает аналогично решить проблему с dh_*?
Использовали схему с пакетами для релизов своих проектов, но отказались в пользу тагированного деплоймента из меркуриала. Потому как второе было быстрее в случае небольших срочных патчей и легче разделялось на sandbox/prod deployment. Но вообще схема с пакетами во многих случаях хороша, да — особенно в плане автоматических зависимостей.
Йех, разработчики на интерпретируемых языках ну совсем обленились =).
Имхо, отсутствие системы билдинга даже helloworld.(py|php|pl|whatever) проекта — глупость, которая замедляет и обостряет production-развертывание.
И мне Ant как-то роднее. Переработал. Пригодилось. Спасибо!
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории