 |
Otros idiomas Deutsch ; English ; Español ; Français |
Por favor quite {{Draft-es}}, cuando este seguro de que la pagina esta completa y correcta.
|
Contents
¿Por qué empaquetar?
Las personas que escriben software normalmente lo ponen en su sitio web y le dicen a los usuarios como compilarlo. Posteriormente, introducen nuevas funcionalidades, algunas veces opcionales (lo que introduce nuevas dependencias), y entender como compilar de la forma que se necesita se va haciendo cada vez más difícil. Aquí es donde los mantenedores de paquetes intervienen. En una distribución binaria, empaquetamos los programas compilados, algunas veces los dividimos en partes para las funcionalidades opcionales, de este modo las personas solo tienen que instalar el paquete y el programa funcionara (asumiendo que hemos realizado nuestro trabajo correctamente).
Empaquetar no es un trabajo simple y el paquete configura la aplicación de modo que sea aceptable para la mayoría de los usuarios de alguna distribución GNU/Linux en particular, lo que significa que , de ser posible, siempre es mejor instalar paquetes creados específicamente para su distribución.
Si desea conocer más sobre el empaquetado, y tal vez sobre como empaquetar su propia aplicación, ¡continué leyendo!
Entendiendo el empaquetado
En términos generales, empaquetar es el proceso de automatizar el trabajo de compilación, con todo lo que implica como el enlace de dependencias. En términos prácticos se compila una aplicación y se empaqueta junto con scripts y otras informaciones requeridas para instalarse en el sistema sin requerir conocimientos especializados en software.
Términos específicos
En orden alfabético:
| arch | arquitectura del procesador, p. ej: i586 (32bit) o x86_64 (64bit) |
| build | (compilar) el proceso de convertir un paquete rpm fuente (SRPM) en un paquete RPM instalable. |
| buildrequires | palabra clave en el archivo spec para designar los paquetes requeridos para compilar (build) un paquete. p.ej. las bibliotecas gtk para las aplicaciones Gnome |
| dependencies | (dependencias) todos los paquetes requeridos para construir un paquete RPM (buildrequires), o para ejecutar un paquete RPM instalado (requires) |
| desktop file | (archivo desktop) un formato de archivo que define los objetos para el menú de aplicaciones |
| patch | (parche) un archivo que lista los cambios que serán aplicados a otro(s) archivo(s) en el SRPM, para solucionar problemas o añadir nuevas características |
| provides | (proporciona) palabra clave en el archivo spec para las funciones proporcionadas por el paquete RPM, normalmente el nombre de algún paquete (casi siempre obsoleto) RPM. |
| RPM | un formato de empaquetado (originalmente Redhat Package Manager -Administrador de Paquetes de Redhat-, actualmente administrado de paquetes RPM). Un archivo RPM contiene todo lo necesario para instalar algún software en particular. Tienen el sufijo .rpm. |
| requires | (requisitos) una palabra clave del archivo spec para paquetes o funciones requeridos para que el paquete RPM funcione adecuadamente tras instalarlo. |
| spec | el archivo .spec dentro del SRPM contiene instrucciones sobre como construir uno o más paquetes RPM |
| SRPM o src.rpm | paquete rpm funte, solo contiene fuentes + parches + archivo .spec . Es utilizado para generar (build) uno o más archivos RPM instalables. |
| suggests | (sugerencias) palabra clave del archivo spec para designar a otros paquetes que se sugiere instalar junto con otro paquete |
| tarball | un archivo con las fuentes. Originalmente se encontraban en formato 'tar' |
| upstream | los desarrolladores (o el sitio web) actuales (generalmente los originales) del software que esta empaquetando |
¿Que es un paquete RPM?
Generalmente una biblioteca y/o un programa, alguna documentación, pagina del manual, etc...
P. ej.
- /usr/lib64/libfoo.so
- /usr/bin/foo
- /usr/share/doc/foo/README
- /usr/share/man/man1/foo.1
¿Que es un paquete SRPM?
Un paquete SRPM frecuentemente contiene un tarball, y un spec, posiblemente parches, y algunas veces archivos adicionales (p. ej: archivos desktop o iconos)
P. ej.
- SPECS/foo.spec
- SOURCES/foo-2.3.5.tar.bz2
- SOURCES/foo-2.3.5-path-to-fix-specific-bug.patch
- SOURCES/foo.desktop
- SOURCES/foo.png
Fácil y Rápido: Como obtener un RPM de un SRPM
Un paquete SRPM son las fuentes sin compilar y es independiente de la arquitectura, mientras que los RPM son binarios compilados y por lo general son dependientes de la arquitectura.
rpmbuild --rebuild file.src.rpm
Esto no instala las buildrequires, necesitara instalarlas manualmente.
Información útil
Un archivo RPM normalmente luce así:
foo-2.3.5-2.mga1.x86_64.rpm
- name: foo
- version: 2.3.5
- release: 2
- disttag: mga
- distrelease: 1
- arch: x86_64
- extension: rpm
Un archivo SRPM generalmente luce así:
foo-2.3.5-1.mga1.src.rpm
- name: foo
- version: 2.3.5
- release: 1
- disttag: mga
- distrelease: 1
- extension: src.rpm
(o podría verlo como arch == src)
Un tarball nomalmente luce así:
foo-2.3.5.tar.bz2
- name: foo
- version: 2.3.5
- extension: tar.bz2
Como podrá ver el nombre (name) y la versión provienen directamente del proyecto (upstream), nosotros no modificamos esto de ninguna manera. release (numero de publicación) es un numero que empieza en 1 y se incrementa si publicamos una actualización con la misma versión.
Un SRPM puede producir más de un RPM
Por ejemplo, el paquete foo-2.3.5-2.mga1.src.rpm puede producir:
- foo-2.3.5-2.mga1.x86_64.rpm : paquete principal que contiene un binario
- lib64foo2-2.3.5-2.mga1.x86_64.rpm : un paquete que contiene un biblioteca necesaria
- foo-data-2.3.5-2.mga1.noarch.rpm : un paquete (independiente de arquitectura) que contiene datos tales como ejemplos del uso del paquete foo
- foo-qt4-2.3.5-2.mga1.x86_64.rpm : un paquete opcional para soporte a Qt4 (KDE)
- foo-gtk-2.3.5-2.mga1.x86_64.rpm : un paquete opcional para soporte a GTK (Gnome)
- foo-devel-2.3.5-2.mga1.x86_64.rpm : un paquete que contiene cabeceras (header) (normalmente son dependencias de construcción -buildrequires- de otros paquetes)
- foo-debug-2.3.5-2.mga1.x86_64.rpm : un paquete generado autmaticamente para depurar foo
Ejemplo A: Preparativos y construcción de su primer rpm
Esto es lo que proponemos:
- comenzar con un paquete existente en su distribución (por ejemplo, la más reciente versión de Mageia).
- Tomemos por ejemplo, 'TeXworks' que es un IDE de LaTeX .
Al terminar esta sección sera capaz de:
- verificar si un software ya esta empaquetado
- tener un ambiente de empaquetado funcional
- crear exitosamente un paquete
- adquirir algo de comprensión sobre las dependencias de construcción y los prerequisitos (utilizando rpm, urpmq y entendiendo la estructura de directorios)
- crear un ambiente para empaquetar software para su actual distribución. El siguiente paso es hacer que lo revisen y enviarlo para poder tener acceso posteriormente al sistema de construcción(build-system)
Preparación preliminar
Por favor siga esta guía para los preparativos preliminares.
Encontrar .rpm y src.rpm
A partir del nombre de la aplicación "TeXworks" encontrar el nombre del rpm:
- Ya sea mediante rpmdrake (en el cuadro de busqueda)
- rápidamente encontrara que el nombre del paquete es texworks
- o utilizando urpmq (o rpm si lo tiene instalado) para encontrar paquetes con nombres similares:
urpmq -a -y TeX
- Si se produce una larga lista de paquetes o no produce ningun resultado, pruebe modificar la búsqueda a una más precisa o más entendible:
urpmq -a -y works
Encontrar el archivo src.rpm:
- Ya sea mediante rpmdrake (si ha configurado el repositorio src)
- o tecleando
urpmq -i texworks
en la ventana de una terminal. Utilizar la linea de comandos no es tan difícil como parece e incluso puede copiar y pegar los comandos que aparecen en esta guía para facilitarle las cosas- asumiremos que ha encontrado esto Source RPM : texworks-0.4.5-1.mga4.src.rpm
Crear el entorno para empaquetar
Si esta intentando construir un paquete para un software escrito en c, necesitara instalar el paquete task-c-devel . Si el software esta escrito en c++ necesitara instalar el paquete task-c++-devel . Al instalar estos paquetes se instalaran también varios más.
Instale el paquete rpm-build :
[root@localhost ~]# urpmi rpm-build
Esto pedirá un montón de dependencias, solo conteste "S" .
También puede instalar bm un administrador de empaquetado más amigable.
Ahora a crear la estructura de directorios:
mkdir -p ~/rpmbuild/{SRPMS,SOURCES,SPECS,tmp}
Posteriormente al instalar un paquete fuente (.src.rpm) o al construir un paquete, se crearan algunos directorios como BUILD, BUILDROOT y RPM.
Entender la estructura de directorios
Una vez obtenido el nombre del src.rpm puede descargarlo de alguno de nuestros repositorios:
cd ~/rpmbuild/SRPMS wget ftp://ftp.mirrorservice.org/pub/mageia/distrib/cauldron/SRPMS/core/release/texworks-0.4.5-1.mga4.src.rpm rpm -ivh texworks-0.4.5-1.mga4.src.rpm
Advertencia, esto no instala los binarios; extrae el spec/tarball+parches en los directorios apropiados.
Instalar las dependencias de construcción
Los paquetes dependen de otros paquetes en varias formas. Para poder construir un paquete debería tener instalados los paquetes requeridos para ello. En muchos casos esos paquetes tendrán el sufijo -devel lo que los identifica como la versión para 'desarrollo' del paquete. Si alguno de los paquetes necesarios no esta instalado cundo (re)construya el paquete vera un mensaje que identifica la causa del problema. En muchos casos estos mensajes diran explicitamente que paquete falta, pero en ocasiones el mensaje puede ser bastante críptico. Afortunadamente es bastante facil instalar los paquetes necesarios.
cd ~/rpmbuild/SPECS su urpmi texworks.spec exit
El comando 'su' le dara permisos de administrador(root), 'urpmi nombre-paqute.spec' instalara los paquetes necesarios. El comando exit lo regresara a su sesión de usuario.
(Re)Construir el src.rpm para crear un rpm
cd ~/rpmbuild/SPECS rpmbuild -ba texworks.spec
Revise ~/rpmbuild/RPMS/i586 (o x86_64 según la arquitectura de su sistema): encontrara los paquetes creados.
bm -l
también reconstruirá el paquete si esta en le directorio actual.
Ejemplo B: Actualizar una RPM a la versión más reciente
Encontrar la versión más reciente del software
Siguiendo con el ejemplo anterior:
- urpmq -i texworks # muestra lo siguiente:
URL : http://www.tug.org/texworks/
- revise la versión estable (stable) más reciente, el sitio muestra 0.4.X?
Construir el paquete para la nueva versión
De la sección anterior ya cuenta con:
- un archivo .spec
- una archivo tarball
- tal vez algunos parches (compruebe si los desarrolladores los han tomado en cuenta)
- (detalles sobre directorios y contenido con algo más de explicación)
Para continuar,
- realice los cambios apropiados (actualice la versión del software y del paquete en el spec, coloque el tarball más reciente en el directorio SOURCES)
- e intente reconstruir hasta que no se generen errores ni advertencias(errors / warnings)
- ya con el .spec actualizado ejecute
rpmbuild -ba texworks.spec
hasta que se construya el archivo RPM - ¡No olvide hacer una instalación de prueba para asegurarse de que funciona!
