Construyendo un paquete RPM para Rosa Linux en la práctica

Si ha estado utilizando el sistema operativo Linux durante mucho tiempo e incluso sabe un poco sobre programación, tarde o temprano necesitará compilar el programa a partir del código fuente. Quizás el programa deseado no estará en los repositorios de distribución. O el programa tiene una versión antigua en estos repositorios, y necesita la última. O tal vez creó un nuevo programa y desea compartirlo con otros usuarios.


Por supuesto, puede instalar el programa de acuerdo con las instrucciones que vienen con el código fuente. Pero luego deberá administrar manualmente los archivos del programa y monitorear sus dependencias. Es mucho mejor crear un paquete con el programa y usar el administrador de aplicaciones integrado en el sistema operativo.


Espero que este artículo le ayude a descubrir rápidamente cómo construir un paquete RPM para Rosa Linux u otra distribución que use el administrador de paquetes RPM (Mandriva, RedHat). O al menos dime dónde buscar información.


Aquí mostraré cómo crear paquetes RPM en mi computadora local, usando un ejemplo simple. Construiremos el programa xkb-switch en el sistema operativo Rosa Linux . Tomaremos el código fuente del programa de GitHub .








Un poco sobre Rosa Linux


Rosa Linux es una distribución creada y respaldada por desarrolladores rusos . Está basado en Mandriva , pero con algunas características. Estoy usando la versión de 32 bits de Rosa Fresh R8 , que se lanzó en 2014. Ahora la versión R8 ya no es compatible con los desarrolladores (los repositorios no están actualizados), pero funciona bien en mi computadora portátil, por lo que no quiero instalar una nueva versión.


Rosa Fresh R8 utiliza el escritorio KDE4 . Todas las versiones del paquete de distribución usan administradores rpm y urpm para administrar paquetes con aplicaciones, y los comandos correspondientes son rpm , urpmi , urpme , urpmq , urpmf .


Los principios de creación de paquetes de software rara vez se modifican dentro de la misma familia de distribución de Linux. Por lo tanto, lo que se describe en este artículo debería funcionar en todas las versiones de distribuciones de Rosa .


Crear paquetes en Rosa Linux es un poco más simple que en otras distribuciones basadas en RPM . Algunos puntos están automatizados y no necesitan configurarse.




Un poco sobre xkb-switch


Me gustó la idea de usar el complemento para el editor de texto Vim - xkbswitch , sobre el cual hay un artículo sobre Habré . Cambia automáticamente la distribución del teclado a inglés cuando sale del modo de entrada, y viceversa, a aquel en el que se ingresó el texto la última vez, si ingresa nuevamente al modo de entrada. Para que este complemento funcione, necesita el programa xkb-switch , que le permite cambiar la distribución del teclado desde la línea de comandos y desde los complementos para el editor Vim . Este programa no estaba en los repositorios Rosa Linux R8 (y probablemente nadie lo agregará, porque la distribución ya es antigua y el programa xkb-switch no es muy popular).




Configurar, finalizar, verificar el programa


A menudo es necesario configurar la compilación del programa para que funcione correctamente en una distribución particular o incluso para un sistema específico. Sucede que un programa debe construirse con otras opciones o con el soporte de algún controlador especial. O tal vez desee corregir errores en el código del programa o simplemente verificar si funciona. Para hacer esto, es mejor copiar el código fuente a su computadora antes de construir el paquete RPM, intente compilarlo y verificar cómo funciona el programa compilado.


Si está seguro de que no necesitará modificar los archivos del proyecto, puede usar el código fuente original del sitio web del proyecto e inmediatamente proceder a construir el paquete. Pero si necesita cambiar la configuración de compilación, generalmente es mucho más fácil cambiar el archivo en la carpeta de origen (el llamado archivo MAKE ) que luego lidiar con las opciones de comando de compilación y el dispositivo macro interno para el archivo de especificaciones.




Verificando el código fuente sin tu perfil en GitHub


Si decide trabajar con el código fuente o la configuración de compilación del proyecto, pero no tiene su propio perfil en GitHub o no quiere usarlo, simplemente puede descargar y descomprimir el código fuente. En nuestro caso, podría verse así (uso la carpeta ~/Projects/cpp para el código fuente de C ++ ):



 cd ~/Projects/cpp git clone https://github.com/ierton/xkb-switch.git 


Esto creará la carpeta ~/Projects/cpp/xkb-switch contiene el código fuente. Por supuesto, en lugar de usar git puede descargar el archivo con el programa y descomprimirlo.


Desde el archivo README.md en la carpeta del proyecto, es fácil adivinar que la utilidad cmake se usa para construir el programa. Por lo tanto, si necesita cambiar la configuración de compilación, en nuestro caso están en el archivo CMakeLists.txt . Y solo tratamos de compilar el programa y verificar si funciona. Los comandos que necesita usar para esto están escritos en el mismo archivo README.md en la raíz del proyecto.



 cd xkb-switch mkdir build && cd build cmake .. make ./xkb-switch #         ./xkb-switch -l #       ./xkb-switch -s ru #       (  ) 


Después de eso, para usar el proyecto modificado, tendrá que borrar o eliminar la carpeta de build del proyecto y empacar el código fuente en el archivo. Podría verse así:



 cd ~/Projects/cpp/xkb-switch rm -rf ./build cd ~/Projects/cpp zip -r xkb-switch.zip xkb-switch 


El archivo xkb-switch.zip usarse para compilar el paquete.




Verificación al guardar el proyecto en su perfil de GitHub


Supongo que cualquiera que lea esta sección está al menos un poco familiarizado con el trabajo con git y ya ha configurado un perfil en GitHub . Creo que este método es el mejor, por lo que el resto del artículo implicará que se usa, a menos que se indique lo contrario.


Primero debes bifurcar el proyecto original en tu GitHub . Después de eso, como en el método anterior, clonamos el proyecto en nuestra computadora, pero desde nuestro repositorio (en mi caso, el nombre de usuario es alexandersolovyov ):



 cd ~/Projects/cpp git clone https://github.com/alexandersolovyov/xkb-switch.git 


Para agregar cualquier cambio, es mejor usar una nueva rama. Luego, si lo desea, será posible utilizar diferentes versiones del programa. Y también será posible proponer cambios al autor del proyecto mediante solicitudes pull. Por ejemplo, si decide arreglar un poco el archivo CMakeLists.txt , antes de eso necesita crear una nueva rama con:



 git branch cmake_corrections 


Después de realizar los cambios, verificarlos y agregarlos a la rama (usando git commit -am " " ), puede agregar una nueva rama a su GitHub:



 git push origin cmake_corrections 


Después de eso, puede hacer una solicitud de extracción, si es necesario.


Puede hacer un enlace al repositorio original:



 git remote add ierton https://github.com/ierton/xkb-switch.git 


Y luego actualice la rama principal de su repositorio para que coincida con el original:



 git pull ierton master 


El código del programa correspondiente a la rama corregida se puede usar al construir el RPM. Para hacer esto, deberá especificar la dirección del archivo en el formulario en el archivo de especificaciones:



 Source0: https://github.com/-/-/archive/---.zip 


Pero, como lo solicitó el usuario de specblog , este no es el caso. Es mejor transmitir sus cambios en forma de parches. Para hacer esto, debe crear archivos de parche a partir de los cambios en su rama y copiarlos en la carpeta de origen para compilar el paquete ( ~/rpmbuild/SOURCES/ ). Luego deberá especificarlos en el archivo de especificaciones. Consideraremos esto un poco más tarde, pero si lo desea, puede leerlo aquí . Si no sabe cómo crear parches, puede mirar debajo del spoiler.




Cómo crear parches usando git

Creando parches


Parches , son parches : son archivos en los que los cambios se registran en el código fuente del programa. Se usan como una alternativa a los comandos git pull y git push para la comunicación entre repositorios de código local si no es conveniente "extraer" los cambios desde un repositorio remoto, o si el historial de cambios del proyecto y los principios de trabajar con él son tales que es mejor usar parches.



Imaginemos que necesitamos hacer cambios en el archivo CMakeLists.txt . Primero, debe hacer todo como se describe anteriormente: la rama maestra en nuestro repositorio de GitHub debe corresponder a la rama principal del proyecto original, y para sus cambios debe usar la rama cmake_corrections . Luego debes ir a esta rama, hacer los cambios necesarios y guardarlos en git usando commits.


Ahora debe guardar los cambios como archivos de parche en la carpeta ~/rpmbuild/SOURCES (si no está utilizando Rosa Linux, la ruta a la carpeta SOURCES puede ser diferente). Por ejemplo, esto (quiero decir que estamos en la carpeta del proyecto, por ejemplo, ~/Projects/cpp/xkb-switch - y en la rama cmake_corrections ):


 git format-patch -o ~/rpmbuild/SOURCES origin/master 

El comando git format-patch crea un archivo de git format-patch para cada confirmación. De esta forma, creará parches a partir de la confirmación especificada por el último argumento y terminando con la última confirmación de la rama actual. Puede especificar una confirmación de cualquier manera: al comienzo del hash, utilizando el puntero HEAD o el nombre de la rama, que ahora indica la confirmación deseada. Lo principal es que uno de los commits que son visibles cuando git log ejecuta git log se toma como un inicio. Es decir, no puede comenzar a hacer parches desde una confirmación que está en otra rama.


Y puede recordar (o ver) cuántas confirmaciones se ramificaron desde la rama principal, y hacer parches para un cierto número de confirmaciones. Por ejemplo, si hiciéramos dos commits, el comando sería:


 git format-patch -o ~/rpmbuild/SOURCES -2 

Aquí el número de confirmaciones se establece usando -2 . Puede especificar cualquier número de ellos en lugar de esta cifra.


Puede especificar el rango de confirmaciones a partir del cual se deben realizar parches colocando dos puntos entre los enlaces a las confirmaciones inicial y final:


 git format-patch -o ~/rpmbuild/SOURCES master..cmake_corrections 

El nombre de cada archivo de revisión consta de un número de serie y la primera línea de un comentario de confirmación. Por lo tanto, es mejor cambiar el nombre de cada archivo para que la descripción del parche describa más breve y claramente su esencia. Por ejemplo, así:


 mv 0001-Return-memory-allocated-by-XkbRf-getNamesProp()-for-tmp.patch 001-Fix-memory-leak.patch 

La convención de nomenclatura para parches en el artículo sobre la sintaxis del archivo de especificaciones recomienda agregar package_name-version-rosa- antes de la descripción de cada archivo de parche. Tal vez esta sea una buena práctica si envía parches por correo electrónico, pero no para crear paquetes. Creamos paquetes en nuestra computadora, por lo que es mejor vaciar la carpeta ~/rpmbuild/SOURCES cada vez antes de ~/rpmbuild/SOURCES paquete con otro programa o un paquete de una nueva versión.


Ahora, si necesita actualizar la rama del repositorio principal ( maestra ) para que coincida con la original, entonces la rama de cambio ( cmake_corrections ) deberá actualizarse utilizando el git rebase . Puedes ver cómo hacer esto aquí . Después de eso, será necesario recrear los parches.





Prepare el "lugar de trabajo" para crear un paquete


Primero necesitas crear una estructura de directorio. Todo el ensamblaje se lleva a cabo en la carpeta rpmbuild en la carpeta de inicio del rpmbuild . Cree la estructura de directorio inicial y vaya a la carpeta para los archivos de especificaciones:



 mkdir -p ~/rpmbuild/SPECS && cd ~/rpmbuild/SPECS 


Para Rosa Linux, esto es suficiente: las carpetas restantes se crearán automáticamente.


Otra distribución puede usar una ubicación de archivo diferente para compilar el paquete. Y quizás deba crear la jerarquía de carpetas completa manualmente. Busque información para su distribución si no está utilizando Rosa Linux. Por ejemplo, esto podría verse así en Red Hat .


Si el paquete se compiló con errores, entonces todos los archivos creados por el comando rpmbuild no se eliminan, lo mismo que con una compilación exitosa. Intentaremos recopilar el paquete muchas veces y los archivos restantes después de la última vez interferirán. Por lo tanto, es mejor crear un script simple que ayudará a eliminarlos rápidamente. Cree un archivo cleanup.sh y póngalo en la ~/rpmbuild/SPECS . Aquí están sus contenidos:



 !#/bin/sh rm -rf ~/rpmbuild/BUILD/* rm -rf ~/rpmbuild/BUILDROOT/* rm -rf ~/rpmbuild/RPMS/* rm -rf ~/rpmbuild/SRPMS/* 


Por supuesto, es mejor agregarle derechos de ejecución usando el chmod u+x cleanup.sh .


Si desea recopilar un paquete de archivos que están en la computadora local, si no está utilizando GitHub y ha realizado cambios en los archivos del proyecto, o si desea crear un paquete desde su propio programa que se almacena solo en su computadora, debe empaquetar el proyecto en un archivo ( por ejemplo .zip , .tar o .tar.gz ) y póngalo en la carpeta SOURCES . Por ejemplo, así:



 cd ~/Projects/cpp/ zip -r xkb-switch.zip xkb-switch mkdir -p ~/rpmbuild/SOURCES cp xkb-switch.zip ~/rpmbuild/SOURCES/ 


Si después de compilar el programa desea compilar otra o la misma versión pero diferente, necesitará eliminar todos los archivos de la carpeta ~/rpmbuild/SOURCES , y luego copiar su archivo allí (si no lo descarga desde GitHub ) y archivos de parches (si se usan). De lo contrario, lo más probable es que el archivo de archivo no se descargue de GitHub (por qué, ver más adelante), y también será difícil determinar qué archivo de parche pertenece a qué programa.




Comencemos a crear un archivo de especificaciones


La base para construir un paquete RPM es el llamado archivo speck . Este archivo contiene las instrucciones para el programa rpmbuild (o más bien rpm ) necesarias para compilar el paquete.


Cree el archivo xkb-switch.spec en la ~/rpmbuild/SPECS/ . La forma más fácil de comenzar es con una plantilla que se puede encontrar en el sitio web de archivos de especificaciones de plantilla .


Desde el README en la página del proyecto xkb-switch , se sabe que el programa se compila utilizando la utilidad cmake . Por lo tanto, seleccionaremos el archivo Spec para un programa creado usando CMake y copiaremos la plantilla completa a nuestro archivo spec. Por supuesto, para ensamblar adecuadamente nuestro paquete RPM, esta plantilla debe cambiarse mucho, lo cual haremos.




Un poco sobre la sintaxis del archivo de especificaciones


  • La sintaxis del archivo de especificaciones le permite agregar comentarios de estilo bash.
  • Puede usar espacios como espacios entre los valores en la misma línea para crear la apariencia de columnas pares, pero la documentación recomienda encarecidamente usar el carácter de tabulación (uno o dos siempre que las columnas sean pares). Nota: en todos los ejemplos de código de este artículo, solo se utilizan espacios, por lo que es mejor no copiar todo el texto de aquí a su archivo de especificaciones, sino imprimirlo usted mismo.
  • Los campos de opción consisten en un nombre de opción especial con dos puntos y el siguiente valor a través de pestañas (o espacios). El caso de los caracteres en los nombres de campo no importa. Por ejemplo:
      Name: xkb-switch 

  • Si la palabra está precedida por el símbolo % (por ejemplo, %description ), entonces esta es una palabra clave especial. Puede ser una llamada de comando, macro o script. Luego, después de esto, se pueden indicar los parámetros que utiliza. Y hay palabras clave que indican el comienzo de un bloque de comandos u opciones. Luego, los parámetros se pueden indicar al lado, y en las siguientes líneas debe haber comandos o una lista de opciones que describí en el párrafo anterior. Después de tal bloqueo, se debe dejar una línea vacía.
  • Para usar el valor de una constante, debe insertar una construcción de la forma %{_} . Su valor puede predefinirse, o puede determinarse mediante una opción (por ejemplo, Name: xkb-switch ) o usando la palabra clave %define . Todas estas constantes también se consideran macros. Su uso se discutirá con más detalle a continuación.



Encabezado de archivo de especificaciones


En el archivo de especificaciones, el encabezado siempre se escribe primero. Esta es una lista de opciones que se aplican al paquete principal de RPM. Cuando el paquete esté listo, casi toda esta información se mostrará al ver su descripción. Esto es lo que indican las líneas individuales:



Resumen:
Una breve descripción del paquete. Vi la descripción en el archivo README.md en el proyecto xkb-switch : Query and change XKB layout state .

Nombre:
El nombre del paquete. En nuestro caso, esto es xkb-switch .

Versión:
Versión del programa Para averiguarlo, es mejor mirar el archivo CMakeLists.txt en la carpeta raíz del proyecto. Por supuesto, debe tomar el archivo de la copia del proyecto que se utilizará para el ensamblaje. Si usa el proyecto original, puede abrir el archivo directamente en su página de GitHub . Como puede ver, la versión está compuesta por MAJOR_VERSION , MINOR_VERSION y RELEASE_VERSION . 1.6.0 versión del programa 1.6.0 .

Lanzamiento
El número de versión del paquete en sí. Muestra a qué hora se está ensamblando un paquete con un programa de la misma versión. En nuestro caso, este es "1", ya que nadie ha ensamblado un programa de esta versión. En el caso ideal, si ya intentamos construir el paquete y el ensamblaje llegó al final (incluso si hubo errores), entonces, después de cada nuevo intento, debe aumentar este número en 1 y al mismo tiempo no eliminar los paquetes recopilados antiguos de las rpmbuild/SRPMS rpmbuild/RPMS y rpmbuild/SRPMS : A continuación, se crearán nuevos paquetes con un nuevo número de compilación. Quizás esto debería hacerse si utiliza un servidor especial para el ensamblaje. Usamos nuestra computadora y en su lugar limpiaremos las carpetas. Si un paquete con un programa de esta versión ya está en los repositorios de la distribución de Linux, pero está compilando con otras configuraciones, entonces es mejor especificar la versión número 1 más que ese paquete.

Licencia:
El nombre corto de la licencia bajo la cual se distribuye el programa. De acuerdo con las reglas de Rosa Linux, solo puede crear paquetes con una licencia que permita la distribución gratuita. README.md encontrar en el archivo README.md que la licencia es GNU GPLv3 . Entonces escribimos: GPLv3+ .

Grupo:
El grupo o categoría a la que pertenece el programa. Con estos grupos, los programas se ordenan en el menú de inicio de la aplicación y en el administrador de programas de la ventana ("Agregar o quitar programas"). La lista de grupos para Rosa Linux se puede encontrar aquí . Creo que Development\X11 es lo mejor para nosotros, ya que el programa está relacionado con X11 y es principalmente necesario para crear scripts y complementos para Vim.

URL:
Dirección de Internet donde puede descargar el código fuente original del programa. Se especificará al ver la información del paquete RPM. Este artículo es opcional, pero le indicaremos: https://github.com/ierton/xkb-switch

Fuente0:
El nombre del archivo que contiene el código fuente o la dirección de Internet donde se puede descargar. Si especifica una dirección en Internet, durante la primera compilación, el archivo se descargará a ~/rpmbuild/SOURCES/ . Si dicho archivo ya existe, ya no se descargará, es decir, el programa rpmbuild solo usará el nombre de archivo especificado al final de esta URL. Puede especificar solo el nombre del archivo, pero luego deberá colocarse en la carpeta ~/rpmbuild/SOURCES/ manualmente. Es mejor proporcionar la dirección de su copia del proyecto en GitHub. Usé el archivo https://github.com/alexandersolovyov/xkb-switch/archive/master.zip . Puede especificar varias fuentes diferentes para recopilar las fuentes de varios archivos con la ayuda de un archivo speck. Luego, en el nombre de la opción para agregar cada archivo subsiguiente, el número debería aumentar ( Source1 , Source2 , etc.). Estas direcciones de archivo no son visibles cuando se visualiza la información del paquete RPM.

Parche0:
Esta opción no está en el archivo de plantilla. Puede ser útil si decide transferir sus cambios en los archivos de proyecto del programa en forma de parches. En cuanto a la opción Source0 , cada archivo debe indicarse en una línea separada, y el número al final del nombre de la opción debe aumentar cada vez. Los archivos de parche deben ubicarse en la carpeta ~/rpmbuild/SOURCES (al lado del archivo fuente descargado). El nombre de cada archivo debe escribirse sin una ruta. No es necesario especificar todos los archivos de parche aquí, solo pueden ser aquellos que desea aplicar.

BuildRequires:
Paquetes necesarios para construir el programa. La plantilla cmake . El archivo CMakeLists.txt indica que la versión mínima de CMake para ensamblar no debe ser inferior a 2.6 , por lo que es mejor especificar cmake >= 2.6 . Puede agregar otros paquetes, cada uno de ellos en una línea separada, usando la opción BuildRequires: separada. La lista de paquetes necesarios para el ensamblaje se puede encontrar leyendo el README del proyecto y mirando cuidadosamente el archivo CMakeLists.txt (especialmente las FIND_PACKAGE , TARGET_LINK_LIBRARY , FIND_PROGRAM ). Luego, debe encontrar el nombre de paquete correcto en los repositorios utilizando el comando urpmq -a __ . En nuestro caso, el archivo de configuración de compilación ( CMakeLists.txt ) ya contiene líneas que verifican la presencia de los paquetes necesarios en el sistema. Pero es mejor especificar la lista completa aquí también:
 # CMake  2.6   BuildRequires: cmake >= 2.6 #  C/C++ BuildRequires: gcc #    libxkbfile BuildRequires: libxkbfile-devel #   X11   libxkbfile, #  libx11-devel   . #    man: BuildRequires: xz 


Requiere:, Proporciona:
Estas opciones no están en la muestra, pero a veces pueden ser útiles. Establecen dependencias entre paquetes.La opción Providesespecifica las características proporcionadas por el paquete que se está creando. Este puede ser el nombre de la cabecera del archivo de lenguaje C , o el nombre de la biblioteca de vínculos dinámicos, o cualquier función especial. Y la opción Requiresindica de qué capacidades de otros paquetes depende el paquete. Administrador de paquetes ( rpm, urpmu otras personas que utilizan su distribución), en la búsqueda de dependencias que buscan estas oportunidades en lugar de nombres de paquetes. Por Provideslo tanto, es mejor indicar la versión de la Oportunidad proporcionada y para Requiresqué versiones de las Oportunidades proporcionadas son adecuadas. La versión está indicada por signos >=,=, o <=, rodeado de espacios. Por lo general, todas las opciones se indican primero Requires, luego Provides, un nombre de función por línea, lo mismo que para BuildRequires:. Por lo general, cuando se crean paquetes en Rosa Linux, las dependencias se reconocen automáticamente, y estas opciones rara vez necesitan especificarse.

AutoReq:, AutoProv:
si está creando un programa que está escrito en un idioma en el que el administrador de rpm es nuevo, o que es propietario, y las dependencias no se detectan correctamente automáticamente, puede deshabilitar la detección automática de Capacidades (con AutoProv: no) y / o Dependencias (con ayuda AutoReq: no)

% descripción
Este bloque ya no es parte del encabezado, pero está asociado con él. Agregará una descripción completa del programa al paquete RPM. Se debe dejar una línea vacía después. La descripción puede ser la siguiente:
 %description xkb-switch is a C++ program that allows to query and change the keyboard layout state for X11 Window System (XKB) via command line. It provides a command 'xkb-switch', and bindings for API of the Vim text editor via 'libxkbswitch.so'. It is mainly used by a plugin for Vim text editor, vim-xkbswitch. Originally ruby-based code written by J.Broomley. 




Las líneas de la plantilla que comienzan con %filesy %find_langson necesarias solo si crea una aplicación con soporte para varios idiomas, así que elimínelas.


Además, después del comentario de línea divisoria, seguido de comandos y macros que deben completarse antes de empaquetar los archivos. Todos estos comandos están divididos en bloques definidos usando palabras clave especiales.




Preparación de la fuente


El primero es un bloque %prepque indica los comandos para prepararse para la compilación. En ella hay un comando macro %setup. Ella ejecuta un script que hace lo siguiente:



  • , SourceX: ( — Source0: ). , .
  • ~/rpmbuild/SOURCES/ .
  • ~/rpmbuild/BUILD/ .
  • .


-q , .


, %prep :



 rpmbuild -bp ~/rpmbuild/SPECS/xkb-switch.spec 


rpmbuild . , rpm : rpmbuild , . ( root sudo ). rpmbuild , man rpmbuild . , , , — , rpmbuild .


: xkb-switch-1.6.0: No such file or directory . , ~/rpmbuild/BUILD/xkb-switch-1.6.0 , .



 ls ~/rpmbuild/BUILD/ 


, xkb-switch-master . %setup -n . %prep - :



 %prep %setup -q -n xkb-switch-master 


~/rpmbuild/SPECS/cleanup.sh , BUILD , , %prep . , exit 0 . , .


, . %prep . , , :


 %apply_patches 

rpmbuild -bp xkb-switch.spec . — .


Maximum RPM .


.





%build . README , cmake .. make , - . : , . , %build :



 ~/rpmbuild/SPECS/cleanup.sh rpmbuild -bc ~/rpmbuild/SPECS/xkb-switch.spec 


exit 0 : .


, . shell ( bash zsh, ). rpmbuild , . shell - — . ( .)


- , , , %build shell .


, , . cmake , , , %cmake - , , . ( — CMakeLists.txt ). , .




Instalación


, . %install , , , ~/rpmbuild/BUILDROOT/__-buildroot/ .


__ , Name: -, ( Version: -), ( Release: -), , .


README , make install , build . - - %makeinstall_std -C build , . ( , ):



 ~/rpmbuild/SPECS/cleanup.sh rpmbuild -bi ~/rpmbuild/SPECS/xkb-switch.spec 


, RPM. - , .





, - . , ~/rpmbild/BUILDROOT/ . ( , , tree , - Linux.) , , .debug . , , : .


, , %files -. , , . .


%files -. , . Rosa Linux %prep ( - ). , , , , — . - (, , ).


%files , RPM. , :



 %files %{_bindir}/%{name} %{_libdir}/libxkbswitch.so %{_libdir}/libxkbswitch.so.1 %{_libdir}/libxkbswitch.so.%{version} %{_mandir}/man1/%{name}.1.xz 


-. , , /usr/lib/rpm/macros . , %{_bindir} , %{_libdir} — , %{_mandir} — man. %{name} %{version} Name: Version: -.


:



 ~/rpmbuild/SPECS/cleanup.sh rpmbuild -ba ~/rpmbuild/SPECS/xkb-switch.spec 


… 2 1 . rpmlint , . , , Rpmlint Errors , :


`xkb-switch.i586: E: incoherent-version-in-name (
Error: 50) 1` Error: La versión en el nombre del paquete de la biblioteca no se ha especificado correctamente.

`xkb-switch.i586: E: ejecutable-en-paquete-biblioteca (Mal: 1) / usr / bin / xkb-switch`
Error: el paquete de biblioteca contiene un archivo ejecutable.

`xkb-switch.i586: W: devel-file-in-non-devel-package / usr / lib / libxkbswitch.so`
Advertencia de que se encontró un archivo de paquete de desarrollo ( -devel) en un paquete que no estaba destinado al desarrollo.



¿Está todo claro? No lo creo Echemos un vistazo más de cerca a lo que está sucediendo aquí.




¿Qué es rpmlint?


Rosa Linux rpmbuild rpmlint , . rpmlint , , . , Rosa Linux ( , rpmlint ) .


, , . ~/rpmbuild/RPMS/_/ rpmlint -i __ .


, RPM - , , , , Rosa Linux, rpmlint -i __ .




RPM Rosa Linux


Rosa Linux 6 . , .


Paquete ejecutable
Es binario. Contiene solo un archivo binario o script destinado directamente a la ejecución. Los archivos de estos paquetes se instalan con mayor frecuencia en una carpeta /bin/o en /usr/bin. También puede contener enlaces, por la posibilidad de llamar al programa usando varios nombres diferentes. El nombre del paquete corresponde al nombre del programa. Dichos paquetes a menudo dependen de la biblioteca.

Biblioteca
Contiene archivos compilados de bibliotecas conectadas dinámicamente ("compartidas", "compartidas") utilizadas por los programas. Por lo general, este es el archivo de la biblioteca en sí, cuyo nombre termina con la versión, y un enlace a este archivo, cuyo nombre termina con el primer número de versión. Por ejemplo, para una libxkbfileversión de biblioteca 1.0.2 será un archivo libxkbfile.so.1.0.2y un enlace a él,libxkbfile.so.1. El mismo nombre del paquete de la biblioteca, por el cual se reconoce en el repositorio del instalador, termina con el primer número de versión y comienza con el prefijo lib. La biblioteca tiene el libxkbfilenombre correcto - libxkbfile1. Esto se debe al hecho de que, por lo general, el número de la primera versión cambia solo con cambios de biblioteca incompatibles, por lo que será posible instalar varios paquetes con una biblioteca de versiones diferentes si algunos programas usan la versión anterior de la biblioteca y otros usan una versión más nueva.

Paquete para desarrolladores
Archivos necesarios para compilar programas que usan la biblioteca, pero innecesarios para el trabajo de programas listos. Para programas simples de C / C ++ , este es un enlace al archivo de la biblioteca, pero sin versiones en el nombre (por ejemplo,libxkbfile.so), así como los archivos de encabezado (con la extensión .h). Nombre del paquete termina con -devel, por ejemplo: libxkbfile-devel. Durante la instalación, siempre depende de la biblioteca adecuada. Por ejemplo, el paquete libxkbfile-develdepende de libxkbfile1.

Código fuente Los
repositorios Rosa Linux tienen paquetes RPM que contienen el código fuente de algunos programas, principalmente aquellos que realmente necesitan ser reconstruidos. Los nombres de estos paquetes terminan con -srco -source(por ejemplo, apache-source). rpmbuildsiempre crea dicho paquete automáticamente y lo pone en ~/rpmbuild/SRPMS/.

Símbolos de depuración
Esta es información que se puede usar para depurar un programa terminado. Asocia ubicaciones en archivos compilados con código fuente. Dichos paquetes son creados rpmbuildautomáticamente por el equipo , se asigna un final a su nombre -debuginfo. No encontré dichos paquetes en los repositorios de Rosa Linux.

La documentación
Los repositorios Rosa Linux tienen paquetes de documentación para varios programas y bibliotecas. Yo (por ahora) no conozco las características de construir tales paquetes. Sus nombres suelen terminar en doc, por ejemplo libx11-doc, java-1.7.0-openjdk-javadoc. Por cierto, casi todos están hechos al estilo de los sitios web, y para verlos, es mejor abrir un navegador, ir a la dirección file:///usr/share/doc/y seleccionar la carpeta y el archivo deseados.




Nuestro resultado


Ahora todo se ha vuelto más claro.



  • xkb-switch libxkbswitch.so , , , . , : xkb-switch.i586: W: devel-file-in-non-devel-package /usr/lib/libxkbswitch.so .
  • , /usr/lib/libxkbswitch.so.1 /usr/lib/libxkbswitch.so.1.6.0 . , . : xkb-switch.i586: E: executable-in-library-package (Badness: 1) /usr/bin/xkb-switch .
  • , (1). : xkb-switch.i586: E: incoherent-version-in-name (Badness: 50) 1 .


, rpmlint , . . xkb-switch , libxkbswitch.so.1.6.0 , Vim . xkb-switch , C C++ . RPM- .


-:



- xkb-switch
 Summary: Query and change XKB layout state Name: xkb-switch Version: 1.6.0 Release: 1 License: GPLv3+ Group: Development/X11 URL: https://github.com/ierton/xkb-switch Source0: https://github.com/alexandersolovyov/xkb-switch/archive/master.zip BuildRequires: cmake >= 2.6 BuildRequires: gcc BuildRequires: libxkbfile-devel BuildRequires: xz %description xkb-switch is a C++ program that allows to query and change the keyboard layout state for X11 Window System (XKB) via command line. It provides a command 'xkb-switch', and bindings for API of the Vim text editor via 'libxkbswitch.so'. It is mainly used by a plugin for Vim text editor, vim-xkbswitch. Originally ruby-based code written by J.Broomley. %files %{_bindir}/%{name} %{_libdir}/libxkbswitch.so %{_libdir}/libxkbswitch.so.1 %{_libdir}/libxkbswitch.so.%{version} %{_mandir}/man1/%{name}.1.xz #------------------------------------------------------------------ %prep %setup -q -n xkb-switch-master %build %cmake %make %install %makeinstall_std -C build 





— , . , , xkb-switch 3 : , . :



  • /usr/bin/xkb-switch /usr/share/man/man1/xkb-switch.1.xz ,
  • /usr/lib/libxkbswitch.so.1 /usr/lib/libxkbswitch.so.1.6.0 ,
  • /usr/lib/libxkbswitch.so .


-. , ,
- Maximum RPM . - libxkbfile Rosa Linux .


.





- libxkbfile . - :



 %define major 1 %define libname %mklibname xkbswitch %{major} %define develname %mklibname -d xkbswitch 


%define . , ( ) — , . , %{major} 1 , .


%mklibname «lib», , — ( ). %{libname} «lib» + «xkbswitch» + ( %{major}) = libxkbswitch1 — .


-d %mklibname -devel . %{develname} libxkbswitch-devel — .





Version:



 Version: %{major}.6.0 


, -.


- . . :


 Name: xkb-switch Version: %{major}.6.0 Release: 1 Summary: Query and change XKB layout state License: GPLv3+ Group: Development/X11 URL: https://github.com/alexandersolovyov/xkb-switch Source0: https://github.com/alexandersolovyov/xkb-switch/archive/master.zip BuildRequires: cmake >= 2.6 BuildRequires: gcc BuildRequires: libxkbfile-devel BuildRequires: xz %description xkb-switch is a C++ program that allows to query and change the keyboard layout state for X11 Window System (XKB) via command line. It provides a command 'xkb-switch', and bindings for API of the Vim text editor, a library 'libxkbswitch'. It is mainly used for some plugins for Vim text editor, such as vim-xkbswitch. Originally ruby-based code written by J.Broomley. 




- . - , - ( rpm ). %package . -. , -. Version , Summary , Group . Provides Requires , . Name : , %package .


. %description — , %package .


Rosa Linux - %description -. libxkbswitch1 :


 %package -n %{libname} Version: %{version} Summary: A library for xkb-switch tool, provides API bindings for Vim text editor Group: Development/X11 %description -n %{libname} libxkbswitch library, required by xkb-switch tool. It provides bindings for API of the Vim text editor, which can be used via 'libxkbswitch.so.1'. 


-n %package %description , . - , xkb-switch-libxkbswitch1 . libxkbswitch1 . .


:


 %package -n %{develname} Version: %{version} Summary: Development library libxkbswitch, provides API bindings for Vim text editor Group: Development/X11 %description -n %{develname} Development files for libxkbswitch. Provides bindings for API of the Vim text editor via 'libxkbswitch.so'. 




, . %files .


, , %package , %description %files . , %description - . , , — xkb-switch .


- Rosa Linux %files , %prep . :


 %files %{_bindir}/%{name} %{_mandir}/%{name}.1.xz %files -n %{libname} %{_libdir}/libxkbswitch.so.%{major} %{_libdir}/libxkbswitch.so.%{version} %files -n %{develname} %{_libdir}/libxkbswitch.so 


, :



  • xkb-switch ~/usr/bin/xkb-switch ~/usr/share/man/man1/xkb-switch.1 ,
  • libxkbswitch1 ~/usr/lib/libxkbswitch.so.1 ~/usr/lib/libxkbswitch.so.1.6.0 ,
  • libxkbswitch-devel ~/usr/lib/libxkbswitch.so .


cleanup.sh rpmbuild -ba ~/rpmbuild/SPECS/xkb-switch.spec . 3 :



 libxkbswitch1.i586: W: no-documentation libxkbswitch-devel.i586: W: no-documentation libxkbswitch-devel.i586: W: no-dependency-on libxkbswitch/libxkbswitch-libs/liblibxkbswitch 


, . , . . Tratemos de resolverlo.





, , , README.md . %files%doc :



 %doc README.md 


. %doc — . ~/rpmbuild/BUILD/xkb-switdh-master/README.md .


: libxkbswitch-devel.i586: W: no-dependency-on libxkbswitch/libxkbswitch-libs/liblibxkbswitch . , libxkbswitch-devel libxkbswitch .


rpm -qp -- . :


 [user@pc ~] $ cd ~/rpmbuild/RPMS/i586/ [user@pc ~/rpmbuild/RPMS/i586] $ ls libxkbswitch1-1.6.0-1-rosa2014.1.i586.rpm xkb-switch-1.6.0-1-rosa2014.1.i586.rpm libxkbswitch-devel-1.6.0-1-rosa2014.1.i586.rpm xkb-switch-debuginfo-1.6.0-1-rosa2014.1.i586.rpm [user@pc ~/rpmbuild/RPMS/i586] $ rpm -qp --provides libxkbswitch1-1.6.0-1-rosa2014.1.i586.rpm libxkbswitch.so.1 libxkbswitch1 = 1.6.0-1:2014.1 [user@pc ~/rpmbuild/RPMS/i586] $ rpm -qp --provides libxkbswitch-devel-1.6.0-1-rosa2014.1.i586.rpm devel(libxkbswitch) libxkbswitch-devel = 1.6.0-1:2014.1 [user@pc ~/rpmbuild/RPMS/i586] $ rpm -qp --requires libxkbswitch-devel-1.6.0-1-rosa2014.1.i586.rpm devel(libX11) devel(libgcc_s) devel(libstdc++) devel(libxkbfile) rpmlib(PayloadIsXz) <= 5.2-1 [user@pc ~/rpmbuild/RPMS/i586] $ rpm -qp --requires xkb-switch-1.6.0-1-rosa2014.1.i586.rpm libc.so.6 libc.so.6(GLIBC_2.0) libc.so.6(GLIBC_2.1.3) libgcc_s.so.1 libgcc_s.so.1(GCC_3.0) libstdc++.so.6 libstdc++.so.6(CXXABI_1.3) libstdc++.so.6(GLIBCXX_3.4) libstdc++.so.6(GLIBCXX_3.4.11) libstdc++.so.6(GLIBCXX_3.4.20) libstdc++.so.6(GLIBCXX_3.4.9) libxkbswitch.so.1 rpmlib(PayloadIsXz) <= 5.2-1 


, libxkbswitch1 libxkbswitch.so.1 libxkbswitch1 . xkb-switch libxkbswitch.so.1 , libxkbswitch-devel libxkbswitch1 . , %package libxkbswitch-devel . :



 %package -n %{develname} Version: %{version} Summary: Development library libxkbswitch, provides API bindings for Vim text editor Group: Development/X11 Requires: %{libname} >= %{version} 


, … . libxkbswitch-devel , , . , , rpmbuild .


-, ( README.md ), — :



-
 %define major 1 %define libname %mklibname xkbswitch %{major} %define develname %mklibname -d xkbswitch # Main package. Automaticaly requires libxkbswitch and libxkbswitch-devel Name: xkb-switch Version: %{major}.6.0 Release: 1 Summary: Query and change XKB layout state License: GPLv3+ Group: Development/X11 URL: https://github.com/alexandersolovyov/xkb-switch Source0: https://github.com/alexandersolovyov/xkb-switch/archive/master.zip BuildRequires: cmake >= 2.6 BuildRequires: gcc BuildRequires: libxkbfile-devel BuildRequires: xz %description xkb-switch is a C++ program that allows to query and change the keyboard layout state for X11 Window System (XKB) via command line. It provides a command 'xkb-switch', and bindings for API of the Vim text editor, a library 'libxkbswitch'. It is mainly used for some plugins for Vim text editor, such as vim-xkbswitch. Originally ruby-based code written by J.Broomley. # libxkbswitch %package -n %{libname} Version: %{version} Summary: A library for xkb-switch tool, provides API bindings for Vim text editor Group: Development/X11 %description -n %{libname} libxkbswitch library, required by xkb-switch tool. It provides bindings for API of the Vim text editor, which can be used via 'libxkbswitch.so.1'. # libxkbswitch-devel %package -n %{develname} Version: %{version} Summary: Development library libxkbswitch, provides API bindings for Vim text editor Group: Development/X11 Requires: %{libname} >= %{version} %description -n %{develname} Development files for libxkbswitch. Provides bindings for API of the Vim text editor via 'libxkbswitch.so'. # xkb-switch %files %{_bindir}/%{name} %{_mandir}/man1/%{name}.1.xz # libxkbswitch1 %files -n %{libname} %{_libdir}/libxkbswitch.so.%{major} %{_libdir}/libxkbswitch.so.%{version} %doc README.md # libxkbswitch-devel %files -n %{develname} %{_libdir}/libxkbswitch.so %doc README.md #------------------------------------------------------------------ %prep %setup -q -n xkb-switch-master %build %cmake %make %install %makeinstall_std -C build 




Conclusión


, RPM Rosa Linux ( ). , -. , — , , rpmrc , ABF , — .


— , -, - , — .








rpmbuild -bp specfile.spec
Ejecutar preparación (% prep).

rpmbuild -bc specfile.spec
Ejecutar compilación (build%) y todas las acciones anteriores.

rpmbuild -bi specfile.spec
Run psevdoustanovku (% install) y todas las acciones anteriores.

rpmbuild -ba specfile.spec
Cree paquetes completamente.




Comprobando el paquete terminado


rpmlint -i nombre_archivo_paquete.rpm
Verificación general: qué tan bien se creó el paquete.

rpm -qp --provides package_filename.rpm
Compruebe qué "características" proporciona el paquete.

rpm -qp - requiere paquete_nombre_archivo.rpm
Verifique de qué "capacidades" de otros paquetes depende este paquete.

rpm -qpl nombre_archivo_paquete.rpm
Lista de archivos contenidos en el paquete.

rpm -qpi package-file-name.rpm
Información sobre el paquete (del "encabezado" del archivo de especificaciones o del bloque % package ).



, p . , Rosa Linux, . urpmq , rpm -q . , urpmq -l _ , urpmq --requires _ .




( )


  1. Building RPMs — Quick Start — RPM Rosa Linux.
  2. RPM — , , . .
  3. RPM: spec — - Rosa Linux.
  4. Maximum RPMrpm RPM- RedHat Linux. , Rosa Linux. .
  5. Template Spec Files.spec . , -.
  6. Automatic Build Farm (ABF) — Rosa Linux. , , , .spec . -.
  7. Rpmlint Errors — , rpmlint .
  8. Packaging Group — Rosa Linux.
  9. Rosa Linux .
  10. Git —Git .

Source: https://habr.com/ru/post/464993/


All Articles