Comments 26
при использовании git / mercurial мы тоже защищены от «проблемы с .svn папками». это не проблема, а кривые руки.
+5
Ant автоматом делает исключение служебных файлов VCS. Опция exclude лишняя.
+2
Отлично! Надо будет попробовать, вот только зачем .ini :(
0
UFO just landed and posted this here
Мы раскладываем ключи дежурных из отдела мониторинга вместе с конфигами sudo как раз пакуя их в rpm-ку.
К сожалению, это всё от лени плотно взяться за cfengine/puppet/etc…
К сожалению, это всё от лени плотно взяться за cfengine/puppet/etc…
0
Основной сценарий сборки содержится в файле packege.xml
0
Супер) То, что доктор прописал, особенно для java проектов)
А тоже самое для rpm-based дистрибутивов сделать можно?
А тоже самое для rpm-based дистрибутивов сделать можно?
0
Думаю, да.
+1
Одного не понял — зачем тут ant? Ну то есть ничего против не имею конечно, но обычный Makefile, который debian/rules вполне достаточен, а главное для редактирования приятнее: )
Потом — не вижу вызовов debhelper утилит — все, связанное с питоном к примеру, будете руками делать? Все папки пустые руками? Зря в общем изобретаете, сугубо на мой взгляд: )
Если не прав — пожалуйста укажите на ошибки, может быть я просто недопонял статью.
Потом — не вижу вызовов debhelper утилит — все, связанное с питоном к примеру, будете руками делать? Все папки пустые руками? Зря в общем изобретаете, сугубо на мой взгляд: )
Если не прав — пожалуйста укажите на ошибки, может быть я просто недопонял статью.
+1
Ant мне исторически ближе, а с debhelper сталкиваться не приходилось. Возможно их использование здесь действительно было бы удачней.
0
Если не ошибаюсь, то в текущем вариант deb пакет можно собрать и из под windows машины… А про вариант с debhelper можно подробнее услышать?
0
Можно поподробнее почитать: )
А про сборку пакетов на win-машине, ну кому оно надо? У нас в корне проекта лежит директория debian со стандартным debian/rules, с помощью которой все собирается обычным fakeroot debian/rules binary. Так вот — нет linux на машине разработчика? Соберите пакеты на build-сервере, и не надо заморачиваться на предмет «а вдруг кому то захочется родить ежика против шерсти??».
А про сборку пакетов на win-машине, ну кому оно надо? У нас в корне проекта лежит директория debian со стандартным debian/rules, с помощью которой все собирается обычным fakeroot debian/rules binary. Так вот — нет linux на машине разработчика? Соберите пакеты на build-сервере, и не надо заморачиваться на предмет «а вдруг кому то захочется родить ежика против шерсти??».
0
А если собирать и rpm, и deb одновременно?) Для каждого варианта держать свой дистрибутив?)
-2
Согласитесь, rpm под debian собрать это элементарно. Наверное что то вроде aptitude install rpm понадобится.
0
Можно) Но не очень нравится вариант с установкой всего необходимого) С антом может путь и не совсем true, зато более изящней.
-1
Ничего изящного в нем нет, потому что те утилиты, что существуют для создания пакетов в дистрибутивах много лет уже затачиваются под эти цели. И все что в них есть, вы будете в ant делать руками.
Если вам хочется «красиво», то оно таковым будет до более менее комплексной конфигурации, а потом начнется лес подпорок.
Зачастую в проекте собираются десятки пакетов, с помощью debhelper это делается легко, с помощью любой другой системы вы будете повторять уже существующее.
Я не понимаю, чем плох make в данном случае. Make очень изящен, гораздо изящнее многословного xml.
Если вам хочется «красиво», то оно таковым будет до более менее комплексной конфигурации, а потом начнется лес подпорок.
Зачастую в проекте собираются десятки пакетов, с помощью debhelper это делается легко, с помощью любой другой системы вы будете повторять уже существующее.
Я не понимаю, чем плох make в данном случае. Make очень изящен, гораздо изящнее многословного xml.
0
Все дело в привычке) И опять же для зоопарка машин разработчиков, когда у каждого своя операционная система от Windows, различных Linux дистрибутивов до Mac, ant гарантирует одинаковость сборки всего продукта на любой из приведенных систем.
0
www.debian.org/doc/debian-policy — кури — не хочу!
+1
Использовали схему с пакетами для релизов своих проектов, но отказались в пользу тагированного деплоймента из меркуриала. Потому как второе было быстрее в случае небольших срочных патчей и легче разделялось на sandbox/prod deployment. Но вообще схема с пакетами во многих случаях хороша, да — особенно в плане автоматических зависимостей.
0
Йех, разработчики на интерпретируемых языках ну совсем обленились =).
Имхо, отсутствие системы билдинга даже helloworld.(py|php|pl|whatever) проекта — глупость, которая замедляет и обостряет production-развертывание.
Имхо, отсутствие системы билдинга даже helloworld.(py|php|pl|whatever) проекта — глупость, которая замедляет и обостряет production-развертывание.
0
И мне Ant как-то роднее. Переработал. Пригодилось. Спасибо!
0
Sign up to leave a comment.
Использование deb-пакетов для дистрибъюции кода