Управление версиями файлов спецификаций rpm

Я настраиваю сборочную машину для создания rpm для большого количества очень похожих проектов. Файл спецификаций для каждого проекта немного отличается как по имени, так и иногда по зависимостям и другим атрибутам. У каждого проекта есть собственный репозиторий git, содержащий файлы проекта.

Эти файлы спецификаций существуют и, по правде говоря, полезны только для самой системы сборки; каждый проект можно установить вручную, но я упаковываю его в rpm для простоты автоматического развертывания.

Сама система сборки также имеет собственный репозиторий git.

Должны ли файлы спецификаций быть версионными? И если да, то где? Должен ли каждый файл спецификации иметь версию в репозитории для проекта, с которым он коррелирует? Или все они должны иметь версии в том же репозитории, что и система сборки? И, главное, почему?

Я обеспокоен тем, что изменение версий спецификаций в репозиториях проекта приведет к рассинхронизации файлов друг с другом, поскольку я постепенно улучшаю процесс установки. Я также обеспокоен тем, что версионирование спецификаций в репозитории сборки приведет к тому, что файлы будут забыты при внесении изменений в зависимости.


person Shishire    schedule 08.11.2012    source источник
comment
См. также аналогичные файлы stackoverflow.com/ вопросы/19082451/   -  person MarkHu    schedule 27.04.2016


Ответы (1)


Я работаю над проектом, в котором мы контролируем версии файлов спецификаций RPM в том же дереве каталогов, что и библиотека или проект. Почему? Благодаря этому все аккуратно совмещено. Когда мы обновляем исходный файл в библиотеке, файл спецификации находится прямо здесь, чтобы добавить соответствующую запись в %changelog с подробным описанием того, что было сделано для исправления ошибки или улучшения.

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

person Ogre Psalm33    schedule 10.12.2012