Комментарии 12
2. Смотрели ли вы в сторону http://openbuildservice.org/ который как раз таки заточен под сборку пакетов и интеграцию с репозиториями?
bashприведён исключительно для примера. Смысл собирать в том, что
- Некоторые официальные сборки пакетов, увы, кривые, и их приходится пересобирать.
- Некоторые пакеты (
xfs, X11 Font Server) ранее присутствовали в дистрибутиве, а затем были исключены из него, но по-прежнему представляют интерес для пользователей. - Наконец, кто-то может разрабатывать своё ПО вне инфраструктуры Debian, но ориентироваться на одну конкретную ОС. Использовать для этих целей Open Build Service — перебор.
- Open Build Service — безусловно, хорошая штука, но так сложилось, что в своей работе я уже использую TeamCity. "Боевого" опыта использования Open Build Service у меня нет, так что сделать полноценное сравнение я не смогу.
Беда таких систем сборки конечных пакетов в следующем (мой опыт): нет пересборки по древу зависимостей. (сделать можно, но дикое усложнение и деньги, в случае TC/Bamboo). Сие ведет, в частности, к тому, что тяжело контролировать версии (когда их нужно много). Если пакетов мало, то с OBS нет никакого смысла заморачиваться. В противном случае, проще отправлять таском из CI в OBS.
Спасибо за оценку.
На вопрос, думаю, смогу ответить спустя какое-то время, когда наберётся достаточная статистика по dpkg (пока что не было ни одного NMU или QA Upload).
Пока что вижу, что
- не всякий коммит сопровождается записью в
debian/changelog, что странно - имена авторов изменения в VCS и в
debian/changelogизредка различаются, что тоже странно
Думаю, надо внимательно курить специфичную для Debian литературу (Policy Guide и т. д.).
Могу порекомендовать Вам поднять сборку dpkg, используя статью в кач-ве инструкции, и убедиться во всём воочию.
Похоже, пора переводить статью на английский и писать в debian-devel@lists.d.o с просьбой прокомментировать.
Андрей Рахматуллин из проекта Debian комментирует:
If you use dpkg-buildpackage then the specifics of the last changelog entry don't matter.
Я понял.
Т. е. вопрос скорее в контексте не continuous integration, а continuous delivery. Тогда это не вопрос ко мне или к разработчикам Debian, а задача для автора tcDebRepository, причём имеющая смысл исключительно для сборки пакетов из основной поставки Debian GNU/Linux.
Если я собираю свой пакет на своём сервере, я не вижу проблем в том, чтобы просто сделать инкремент версии в случае, эквивалентном, скажем, binNMU.
Или я что-то упустил?
По поводу своего пакета — тогда врядли актуально. Я тоже собираю свои пакетики для инфраструктуры. Changelog меняю руками. Вполне хватает рук, автоматика не нужна. Все вышесказанное актуально для пакетов основного приложения, которое тестируют, деплоят и обновляют. Где важен конвейер.
Добрые у Вас названия агентов, однако. :-)
TeamCity как Debian-репозиторий