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.
Name: speech
Summary: Script muy útil para convertir un texto a voz
Group: Applications/Multimedia
URL: http://blog.desdelinux.net/script-texto-voz-google-desde-el-terminal/
Version: 1.0
Release: 1%{?dist}
License: GPLv3
Source: t2s
#-------------------------------------
BuildRequires: binutils
#-------------------------------------
Requires: mpg123
%description
Script muy útil para convertir un texto a voz utilizando el motor de google.
%prep
%build
%install
install -dm 755 %{buildroot}/%{_bindir}/
install -m644 %{SOURCE0} %{buildroot}/%{_bindir}/
%files
%{_bindir}/t2s
%changelog
* Fri Jun 27 2014 My Name <email AT gmail DOT com> - 1.0-1
- Initial rpm
Ahora veamos como debería ir nuestro PKGBUILD
# Maintainer: My name <email AT gmail DOT com>
pkgname=speech
pkgver=1.0
pkgrel=1
pkgdesc="Script muy útil para convertir un texto a voz."
arch=('any')
url="http://blog.desdelinux.net/script-texto-voz-google-desde-el-terminal/"
license=('GPLv3')
depends=('mpg123')
makedepends=('binutils')
options=('emptydirs')
source=("t2s")
check=$(md5sum t2s | awk '{print $1}')
md5sums=("$check")
package() {
cd "$pkgdir"
install -dm 755 "$pkgdir/usr/bin/"
install -m644 "$srcdir/t2s" "$pkgdir/usr/bin/"
}
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?
# Maintainer: Your name <Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo.>;
pkgname=yumi
pkgver=0.0.1
pkgrel=1
pkgdesc="Boot and run Linux from a USB flash memory stick"
arch=('any')
url="http://www.pendrivelinux.com"
license=('GPLv3')
depends=('zip' 'gambas3-runtime')
options=('emptydirs')
source=('http://www.pendrivelinux.com/downloads/YUMI/ubuntu/yumi_0.0.1.orig.tar.gz')
md5sums=('77641eeaf77f2d18c27649d288412b54')
package() {
cd "$pkgdir"
install -dm 755 "$pkgdir/usr/bin/"
install -dm 755 "$pkgdir/usr/share/applications/"
install -dm 755 "$pkgdir/usr/share/pixmaps/"
install -m755 "$srcdir/yumi-0.0.1.orig/src/YUMI/YUMI.gambas" "$pkgdir/usr/bin/"
install -m644 "$srcdir/yumi-0.0.1.orig/src/YUMI/yumi.png" "$pkgdir/usr/share/pixmaps/"
cat > $pkgdir/usr/share/applications/$pkgname.desktop << EOF
[Desktop Entry]
Version=1.0
Name=YUMI
Comment=YUMI is Your USB Multiboot Installer! YUMI enables users to easily put multiple Live Linux Operating Systems on a select USB drive, and then run the select Operating System from the USB at boot.
Exec=/usr/bin/YUMI.gambas
Icon=/usr/share/pixmaps/yumi.png
Terminal=false
Type=Application
StartupNotify=true
Categories=System;
EOF
}
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: wiki.archlinux | wiki.archlinux | fedoraproject | fedoraproject
Fuente: kuboosoft
