Empaquetando en Arch Linux/Manjaro

Empaquetando en Arch Linux/Manjaro

  9:36    David Va

---

Siempre he dicho la lectura te puede llevar a lugares nunca esperados; y la creacion de un "pkg.tar.xz" no es una tarea complicada.

En distribuciones como Fedora, Mageia, Openmandriva, openSuse la administración de paquetes varía en comparación con Debian e hijas empezando por el formato.

Debian e hijas utilizan ".deb" en Fedora y otras utilizan "rpm" ¿Cuál es la diferencia? en mi experiencia la diferencia radica en la forma de hacer las cosas, no vengo a dar una cátedra sobre los diferentes tipos de administración de paquetes en Linux. Asi que venga vamos al grano. Para ello como mi experiencia es mas de empaquetado rpm hare pequeñas comparaciones en todo el articulo.

Para crear un rpm necesitamos primero dar las instrucciones de ¿como?, ¿donde?, ¿con que? al cual se le llama spec (ejemplo variety.spec). En Manjaro/Arch se tiene algo similar el cual se le llama solamente PKGBUILD.

No hay nada mejor que un ejemplo no?

Para ello haremos un pequeño pkg.tar.xz para Arch Linux/Manjaro sin arquitectura, cuando me refiero sin arquitectura quiere decir que puede ser instalado sin importar si es de 32 o 64 bits, donde no es necesario compilar absolutamente nada, en próximos artículos veremos como crear un pkg.tar.xz para diferentes arquitecturas.

Para el ejemplo tomaremos con el permiso de nuestros amigos de DesdeLinux un script muy útil para convertir un texto a voz utilizando el motor de voz de Google. 

En Fedora y otros el .spec y PKBUILD cada quien puede dar su toque personal, sin embargo hay etiquetas que deben tener. Venga haremos un spec llamado "speech.spec" que así se llama el script y en base a el crearemos un PKGBUILD. En el siguiente ejemplo se muestra un .spec de speech.

Ahora veamos como debería ir nuestro PKGBUILD




Explicando 

Comparando el speech.spec vrs PKGBUILD, podemos percatarnos que presentan similitudes, una de ellas es que el spec y el PKGBUILD tienen macros, los macros nos ayudan a cortar rutas; muchas veces rutas inteligentes donde pueden variar dependiendo la arquitectura, o simplemente los directorios de trabajo temporal...

Macros

${_pkgver} = versión del programa

${_pkgname} = nombre el programa igual en la etiqueta "pkgname"


$srcdir = ruta extraída del código fuente
 

${pkgdir} = ruta de construcción final


Secciones

prepare
Aqui aplicamos los parches si los hubiera o algun tipo de modificaciòn al código fuente.

build
Procesos de compilación (make...)

package
Instalación en un entorno fakeroot  (make install...)

Partes/etiquetas del PKGBUILD

• El mantenedor [Maintainer],
• Nombre del paquete [pkgname],
• Versión [pkgver],
• Número de release [pkgrel],
• Descripción [pkgdesc],
• Arquitectura [arch],
• Licencia [license],
• Archivo que se incluyen [install],
• Página del paquete [url],
• Dependencias para poder ejecutarse el programa [depends],
• Dependencias de compilación [ makedepends ]; de donde se obtienen las fuentes [source] y md5sum de las fuentes, que comprueban la integridad [md5sum].

Este ultimo (md5sum) hace una comprobación de nuestro código fuente de lo contrario el código fuente esta corrupto. En el ejemplo yo realizo una pequeña modificación para que el md5sum lo incluya automáticamente, ojo no es la forma recomendable pero si usted quiere empaquetar un script o un único binario localmente, se encargará de hacerlo.

Si su codigo fuente tiene muchos archivos lo mejor será generar el md5sum con

makepkg -g

Si son observadores notarán que la etiqueta "build", esta vació o mejor dicho ni existe, eso es porque no hay compilación. Así también "prepare", porque no tenemos necesidad de parchar, modificar o extraer el código fuente.

Debemos recordar que un PKGBUILD siempre debe tener la etiqueta "package" que en un .spec seria "install" esta etiqueta hace exclusivamente un fakeroot donde el programa imitara una instalación para crear el paquete.

En la etiqueta "package" podemos observar el comando "install" uno de mis preferidos debido a que hace un proceso de copiado aplicando los permisos necesarios para ejecucion, edicion etc.

install -dm 755 (nos creara un directorio con permisos "chmod 755"

install -m644 copiará lo que le indiquemos con permisos "chmod 644"

Cuando se compile o se haga un paquete sin arquitectura y otro caso, las rutas deben respetar la FHS (Estándar de jerarquía del sistema de archivos) http://es.kioskea.net/contents/309-linux-estructura-de-arbol-de-los-archivos, http://es.wikipedia.org/wiki/Filesystem_Hierarchy_Standard ; http://www.pathname.com/fhs/

Lo anterior (lineas "install") es equivalente al mkdir -p y cp -f  + chmod... es por eso que anteriormente mencionaba que cualquiera puede darle su toque a un .spec o un PKGBUILD.

Después de crear nuestro PKGBUILD, es necesario crear un directorio, y allí mismo contener el PKGBUILD y el código fuente para luego, hacer un cambio de directorio (cd) hacia su ruta y finalmente crear nuestro paquete.

makepkg -s

Y si se quiere instalar, (recordando la ruta hacia el directorio que usted ha creado).

pacman -U /path/to/pkg.tar.xz

Otro ejemplo?

Explicando este otro ejemplo, donde hacemos un PKGBUILD de Yumi, a petición de nuestros visitantes, la diferencia de este y el anterior radica en los permisos del comando "install" para el ejecutable, además como es un programa, creamos un .desktop para poder ejecutarlo desde cualquier menú. Si observaron este PKGBUILD le incluimos exactamente el md5sum sin una variable. Así también el código fuente ahora incluimos directamente la ruta hacia el sitio donde puede descargarse, pues no es un archivo local lo que queremos empaquetar.

Referencias
https://wiki.archlinux.org/index.php/PKGBUILD_%28Espa%C3%B1ol%29

https://wiki.archlinux.org/index.php/Arch_User_Repository_%28Espa%C3%B1ol%29
https://fedoraproject.org/wiki/How_to_create_an_RPM_package/es
https://fedoraproject.org/wiki/Packaging:RPMMacros?rd=Packaging/RPMMacros