Как я могу использовать git для отслеживания настроек SRPM? - PullRequest
Новая
       5

Как я могу использовать git для отслеживания настроек SRPM?

6 голосов
/ 24 сентября 2011

Наша команда часто выполняет настройку для различных пакетов, распространяемых с RHEL / CentOS.Наш рабочий процесс включает установку SRPM, выполнение rpmbuild -bp для распаковки и исправления исходного кода, внесение наших изменений и создание .patch для включения в specfile, а также создание нового настроенного SRPM для последующего использования с mock: 

$ rpm -i grub-0.97-13.5.1.src.rpm
$ rpmbuild -bp rpmbuild/SPECS/grub.spec
$ cp -a rpmbuild/BUILD/grub-0.97 grub-0.97.orig
$ cd rpmbuild/BUILD/grub-0.97
  # Make modifications, generate .patch against ".orig" copy
$ vim rpmbuild/SPECS/grub.spec
  # Add custom .patch to specfile, update version, etc
$ rpmbuild -bs rpmbuild/SPECS/grub.spec
$ mock -r default-x86_64.cfg rpmbuild/SRPMS/grub-0.97-13.5.1.custom-1.src.rpm

Этот процесс работает хорошо, но в настоящее время мы не используем какую-либо форму контроля версий для отслеживания наших изменений и изменений в спецификациях.Исходя из моего (по общему признанию) базового понимания git, я думаю, что должна быть возможность внедрить его в этот рабочий процесс и использовать некоторые его возможности для оптимизации нескольких шагов (в дополнение к обычным преимуществам SCM).

Например, вместо того, чтобы создавать копию источника в diff против позже, мы могли бы создать начальную фиксацию исходного исправленного источника и затем внести наши изменения.Когда все будет готово, используйте git format-patch, чтобы создать наш патч для функций и добавить его в файл спецификации.

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

Итак, мой вопрос состоит из трех частей:

  1. Кто-нибудь там использует SCM при настройке исходящих пакетов?
  2. Чтосамый эффективный способ интеграции git в наш рабочий процесс?
  3. Есть ли лучший рабочий процесс, который более благоприятен для создания пользовательских RPM-контроллеров с управлением версиями?

Дополнительный кредит: Если предположить, что рабочий процесс основан на git, как я могу структурировать центральное хранилище для приема толчков?Один репо с субмодулями?Один репо на пакет?

1 Ответ

8 голосов
/ 24 сентября 2011

Кто-нибудь использует SCM при настройке исходящих пакетов?

Конечно. Это довольно часто.

Каков наиболее эффективный способ интеграции git в наш рабочий процесс? Есть ли лучший рабочий процесс, который более благоприятен для контроля версий пользовательская авторизация RPM?

Я не знаю о наиболее эффективных , но вот что я делаю. Я начинаю с следующий ~/.rpmmacros файл: 

%_topdir    %(echo ${RPM_TOPDIR:-$HOME/redhat})
%_specdir   %{_topdir}/PACKAGES/%{name}/%{version}
%_sourcedir %{_topdir}/PACKAGES/%{name}/%{version}/sources
%_rpmdir    %{_topdir}/PACKAGES/%{name}/%{version}/rpms

Если я устанавливаю пакет (скажем, foo-1.0-1.src.rpm), файл спецификаций заканчивается в ~/redhat/PACKAGES/foo/1.0/foo.spec, и архив с исходным кодом (и любой патчи) в конечном итоге в ~/redhat/PACKAGES/foo/1.0/sources.

Теперь я инициализирую каталог пакета как репозиторий git: 

cd ~/redhat/PACKAGES/foo/1.0
git init
git add foo.spec sources/*.patch
git ci -m 'initial commit'

Нет ничего особенного в записи изменений в файле спецификации: 

git ci -m 'made some really spiffy changes' foo.spec

Если мне нужно внести изменения в исходные файлы пакета, я делаю это: 

rpmbuild -bp foo.spec

А теперь я создаю временный репозиторий git: 

cd ~/redhat/BUILD/foo-1.0
git init
git add .
git ci -m 'initial commit'
git tag upstream

С этого момента, если я сделаю какие-либо изменения, я могу сгенерировать патчи против исходный пакет вроде этого: 

git diff upstream

Или, если я сделал серию коммитов, я могу использовать команду git's format-patch создать серию патчей: 

$ git format-patch upstream
0001-added-text.patch
0002-very-important-fix.patch

И их можно скопировать в соответствующий каталог sources и добавить в файл спецификации.

Обратите внимание, что временный git-репозиторий, который я создал для отслеживания изменений в каталог сборки будет уничтожен при следующем запуске rpmbuild.

...