¿Cómo puedo usar git para rastrear personalizaciones de SRPM?

Question

Nuestro equipo realiza con frecuencia la personalización de varios paquetes distribuidos con RHEL/CentOS. Nuestro flujo de trabajo incluye la instalación de la SRPM, ejecutando rpmbuild -bp para desempaquetar y parchear la fuente, haciendo que nuestros cambios y crear un .patch para ser incluido en el specfile, y la construcción de la nueva SRPM personalizado para su uso posterior con fingida:

$ 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 

Este proceso funciona bien, pero actualmente no estamos utilizando ningún tipo de control de origen para realizar un seguimiento de nuestras modificaciones y cambios en el archivo de la especificación. Basado en mi comprensión (ciertamente básica) de git, creo que debería ser posible inyectarlo en este flujo de trabajo y aprovechar parte de su poder para optimizar algunos de los pasos (además de los beneficios normales de SCM).

Por ejemplo, en lugar de crear una copia de la fuente a diff en una fecha posterior, podríamos crear una confirmación inicial de la fuente de parche de inicio y luego hacer nuestras modificaciones. Cuando esté listo, use git format-patch para crear nuestro parche de características y agréguelo al archivo de especificación.

También me gustaría controlar la versión de los archivos de especificación, aunque no estoy seguro de cómo lograrlo.

---

Así que mi pregunta es triple:

1. ¿Alguien por ahí utilizar SMC cuando personalización de paquetes de aguas arriba?
2. ¿Cuál es la forma más efectiva de integrar git en nuestro flujo de trabajo?
3. ¿Existe un mejor flujo de trabajo que sea más propicio para la creación de RPM personalizada controlada por versión?

Crédito adicional: Suponiendo un flujo de trabajo basado en git, ¿cómo iba a estructurar un repositorio central para aceptar empuja? Un repositorio con submódulos? Un repo por paquete?

Answer 1

¿Hay alguien por ahí que use SCM al personalizar paquetes en sentido ascendente?

Sure. Esto es bastante común.

¿Cuál es la forma más efectiva de integrar git en nuestro flujo de trabajo? ¿Existe un mejor flujo de trabajo que sea más propicio para la creación de RPM personalizada controlada por la versión ?

no sé acerca más eficaz, pero aquí es lo que hago. Empiezo con la ~/.rpmmacros siguiente archivo:

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

Si instalo un paquete (por ejemplo, foo-1.0-1.src.rpm), el archivo de especificación termina en ~/redhat/PACKAGES/foo/1.0/foo.spec, y el paquete fuente (y cualquier parche ) terminan en ~/redhat/PACKAGES/foo/1.0/sources.

Ahora inicializar el directorio del paquete como un repositorio git:

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

No hay nada especial acerca de los cambios de registro en el archivo de especificaciones:

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

Si tengo que hacer cambios para empaquetar los archivos de origen , Hago esto:

rpmbuild -bp foo.spec 

Y ahora creo un repositorio git temporal RY:

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

A partir de ahora, si hago cualquier cambio que pueda generar parches contra el paquete originales de esta forma:

git diff upstream 

O si he hecho una serie de confirmaciones, me puede utilizar el comando git de format-patch para crear una serie de parches:

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

y estos pueden ser copiados en elapropiadadirectorio y agregó al archivo de especificación.

Tenga en cuenta que el repositorio de git temporal que he creado para rastrear los cambios en el directorio de compilación se borrará la próxima vez que ejecute rpmbuild.