linux - ¿un archivo de especificaciones de RPM "incluye" otros archivos?

scripting rpm-spec

Question

¿Existe algún tipo de directiva de "inclusión" en las especificaciones de RPM? No pude encontrar una respuesta buscando en Google.

Motivación : Tengo una plantilla de especificaciones de RPM que el proceso de compilación modifica con la versión, revisión y otros datos específicos de compilación. Esto es hecho por sed actualmente. Creo que sería más claro si la especificación #include un archivo de definiciones específicas de la compilación, que sería generado por el proceso de compilación, por lo que no es necesario buscar y reemplazar en la especificación.

Si no hay include , ¿hay una manera idiomática de hacer esta tarea (bastante común, creo)?

Answer 1

¿De qué versión estás hablando? Actualmente tengo% include filename.txt en mi archivo spec y parece funcionar igual que la directiva C # include.

> rpmbuild --version
RPM version 4.8.1

Answer 2

RPM no admite incluye.

He resuelto problemas similares con el macroprocesador m4 o simplemente concatenando partes de la especificación (cuando el "incluir" estaba al principio).

Si solo necesita pasar algunas variables en el momento de compilación, y no incluir varias líneas de otro archivo, puede ejecutar

rpmbuild --define ''myvar SOMEVALUE'' -bb myspec.spec

y puedes usar% myvar en la especificación.

Answer 3

Las versiones suficientemente recientes de rpmbuild ciertamente admiten% incluyen:

%include common.inc

Desafortunadamente, no son muy inteligentes al respecto: no existe un conjunto conocido de directorios, en el que buscará los archivos solicitados, por ejemplo. Pero está ahí y las variables se expanden, por ejemplo:

%include %{_topdir}/Common/common.inc

Answer 4

He usado scripts (nombre tu favorito) para tomar una plantilla y crear el archivo de especificación a partir de eso. Además, la etiqueta %files puede importar un archivo creado por otro proceso, por ejemplo, bdist-rpm Python.

Answer 5

Para el problema subyacente, hay quizás dos soluciones adicionales que están presentes en todas las versiones de rpm que conozco.

1. Subpaquetes
2. macro y archivos rpmrc .

Subpaquetes

Otra alternativa (y tal vez la " forma de RPM ") es usar subpaquetes . Maximum RPM también tiene información y ejemplos de subpaquetes .

Creo que la pregunta es tratar de estructurar algo así como,

• dos archivos de especificaciones; digamos rpm_debug.spec y rpm_production.spec
• ambos usan %include common.spec

la depuración y la producción también pueden ser cliente y servidor , etc. Para los ejemplos de redefinición de una variable, cada subpaquete puede tener su propia lista de variables.

Limitaciones

La principal ventaja de los subpaquetes es que solo se realiza una compilación ; Esto también puede ser una desventaja. El ejemplo de depuración y producción puede resaltar esto. Eso se puede solucionar usando strip para crear variantes o compilando dos veces con diferentes resultados; quizás usando VPATH con Gnu Make). Tener que compilar paquetes grandes y luego solo tener variaciones simples, como con / sin información del desarrollador, como headers , bibliotecas estáticas , etc., puede hacer que aprecien este enfoque.

Macros y Rpmrc

Los subpaquetes no resuelven el problema de las definiciones estructurales que desea para una jerarquía de rootfs completa o una colección más grande de RPM. Tenemos rpmbuild --showrc para esto. Puede tener una gran cantidad de variables y macros definidas alterando rpmrc y macros cuando ejecuta rpm y rpmbuild . Desde la página man ,

   rpmrc Configuration
       /usr/lib/rpm/rpmrc
       /usr/lib/rpm/redhat/rpmrc
       /etc/rpmrc
       ~/.rpmrc

   Macro Configuration
       /usr/lib/rpm/macros
       /usr/lib/rpm/redhat/macros
       /etc/rpm/macros
       ~/.rpmmacros

Creo que estas dos características pueden resolver todos los problemas que %include . Sin embargo, %include es un concepto familiar y probablemente se haya agregado para que las rpm sean más completas y amigables para los desarrolladores.

Answer 6

Me enfrenté a este mismo problema recientemente. Quería definir varios subpaquetes que fueran similares, pero cada uno variaba ligeramente (eran RPM específicos del idioma). No quería repetir el mismo material de la placa de calderas para cada subpaquete.

Aquí hay una versión genérica de lo que hice:

%define foo_spec() %{expand:%(cat ''%{myloc}/main-foo.spec'')}
%{foo_spec bar}
%{foo_spec baz}
%{foo_spec qux}

El uso de %{expand} asegura que %(cat) solo se ejecuta una sola vez, cuando se define la macro. El contenido del archivo main-foo.spec es entonces tres veces, y cada vez %1 en el archivo main-foo.spec se expande a cada una de las bar , baz y qux , lo que me permite tratarlo como una plantilla. Podrías expandir esto fácilmente a más de un parámetro, si tienes la necesidad (no lo hice).

Answer 7

Puede incluir los archivos *.inc del directorio SOURCES ( %_sourcedir ):

Source1: common.inc

%include %{SOURCE1}

De esta forma irán automáticamente a SRPMS .