Compartir
Publicidad

Guía rápida de desarrollo de paquetes para Gentoo Linux

Guía rápida de desarrollo de paquetes para Gentoo Linux
Guardar
9 Comentarios
Publicidad
Publicidad

Por si no la conoces, Gentoo es una distribución de GNU/Linux inspirada en la filosofía de FreeBSD. Es una distribución extremadamente ligera que puede ser optimizada y tuneada hasta adaptarse completamente a nuestras necesidades. Es extremadamente configurable y, según sus autores, asegura la mejor experiencia a los usuarios avanzados de Linux.

Gentoo no solo es una distribución más, es además una filosofía y una forma de entender Linux, es habitual encontrar posts en foros y blogs que hacen referencia al "Gentoo's Way". La filosofía que inspira a Gentoo se basa en ciertos principios inamovibles como la libertad, la flexibilidad y el control total sobre la distribución. Es frecuente que los usuarios experimentados de Linux que en alguna etapa utilizan Gentoo, no vuelvan a ninguna otra distribución puesto que ninguna otra aporta la flexibilidad extrema que se consigue con Gentoo.

Como todas las distribuciones de Linux, Gentoo cuenta con un sistema de instalación de paquetes, solo que en Gentoo es un poco especial. Gentoo no instala paquetes precompilados como hacen el resto de distribuciones de Linux, Gentoo descarga las fuentes de los paquetes a instalar, las compila (en caso de que sean fuentes compilables) y las instala en el sistema a través de un potente sistema llamado Portage que es de hecho, el corazón de la distribución.

Portage es un sistema dual, sirve tanto para construir paquetes como para instalarlos. Para realizar una instalación de un paquete en Gentoo se utiliza la herramienta emerge, la construcción de paquetes es realizada por la herramienta ebuild que es invocada por emerge de forma automática y se encarga de descargar, descomprimir, aplicar parches, compilar, enlazar, instalar y limpiar los paquetes.

Obviamente, todas esas tareas no se ejecutan de forma "automágica" sino que el sistema Portage hace uso de unos archivos de configuración que componen el árbol de instalación llamados (viva la originalidad) ebuilds. Hoy vamos a dar un vistazo rápido a los conceptos generales de un archivo ebuild y aprender un poco más del desarrollo de paquetes para Gentoo.

Reglas de nomenclatura de un archivo Ebuild

Un ebuild debe de tener el formato nombre-version.ebuild. El nombre puede contener caracteres alfanuméricos en minúsculas, guiones, guiones bajos y el símbolo del más. Los caracteres en mayúsculas, aunque válidos están desaconsejados por la guía de desarrollo de Gentoo y si los usas es muy probable que tus paquetes no pasen el corte y nunca sean añadidos a la distribución.

La versión contiene uno o más números separados por puntos y puede ir sucedido de una única letra que sirve para indicar el estado del paquete, por ejemplo 'b' para indicar el estado 'beta' de un paquete en el árbol. Portage trata a un paquete digamos denominado nombre-paquete.2.4b como una versión posterior a 2.4a o 2.4. También se puede añadir sufijos indicando el tipo de release del paquete en cuestión. El orden de menor a mayor es el que se muestra en la siguiente tabla:

SufijoSignificado
_alphaVersión Alfa
_betaVersión Beta
_prePrelanzamiento
_rcCandidata para Liberar
(sin sufijo)Versión Normal
_pNivel de Parche

Cada uno de estos sufijos puede ir acompañado de un número entero no negativo. Además estos sufijos pueden ir precedidos o sucedidos por cualquier otro de los sufijos. Por ejemplo:

  • fake-2.1.4_beta_rc2

La versión también puede llevar una versión específica refiriéndose al número de revisión del paquete por parte de Gentoo. Para añadir esta versión se usa un guión una r y el número de la revisión. La revisión inicial del paquete no lleva este sufijo. El aspecto posible del nombre completo de un paquete ebuild puede ser como el que sigue:

  • firefox-4.0.1-r1.ebuild

El formato de un archivo Ebuild

Como ya habrás imaginado, para entender el sistema de paquetes de Gentoo en profundidad, debes de saber lo que es y como funciona un compilador, conocer las diferencias entre las diferentes arquitecturas y en general debes de entender como funciona el enlazador y como es el uso que Linux hace de éste. Los ebuilds (que usan la extensión .ebuild) se componen de instrucciones escritas en bash y aunque no son archivos bash completamente válidos, si que comparten estructura y sintaxis. Vamos a verlo, editemos por ejemplo el ebuild (fake, la versión real no es así pero lo he editado para simplificarlo) del editor modo texto vim:

# Copyright 1999-2011 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/app-editors/vim/vim-7.3.75.ebuild,v 1.1 2010/12/08 20:19:54 lack Exp $
DESCRIPTION="Vim, an improved vi-style text editor"
HOMEPAGE="http://www.vim.org/"
LICENSE="vim"
SRC_URI="ftp://ftp.vim.org/pub/vim/unix/vim-${PV}.tar.bz2"
SLOT= "0"
KEYWORDS="~alpha ~amd64 ~arm ~hppa ~ia64 ~m68k ~mips ~ppc ~ppc64 ~s390 ~sh ~sparc ~x86 ~ppc-aix ~sparc-fbsd ~x86-fbsd ~x64-freebsd ~x86-freebsd ~ia64-hpux ~x86-interix ~amd64-linux ~x86-linux ~ppc-macos ~x64-macos ~x86-macos ~m68k-mint ~sparc-solaris ~sparc64-solaris ~x64-solaris ~x86-solaris"
src_compile() {
    econf --with-posix-regex
    emake || die
}
src_install() {
    emake DESTDIR="${D}" install || die    
    dodoc FAQ NEWS README || die   
}

No te preocupes en exceso si no entiendes absolutamente nada

Cabecera

Al principio del script (que como puedes ver es un script en bash normal y corriente) se encuentra el bloque de cabecera. Todos los ebuilds deben de llevar un bloque de cabecera para que sean aceptados como válidos. Deben de ser tres líneas indicando el copyright que es una copia del contenido del archivo /usr/portage/header.txt. Si somos developers de Gentoo, la parte correspondiente al CVS será rellenada de forma automática por el servidor de CVS de Gentoo

Reglas de estilo

La indentación de los ebuilds debe de ser hecha con tabs de 4 espacios. Se utiliza un tab por cada nivel de indentación. Es necesario evitar los espacios en blanco porque la herramienta de repositorios de Portage repoman se quejará si encuentra espacios en blanco en nuestro ebuild. Usar espacios está considerado una mala práctica. Al igual que en el PEP8 de Python, siempre que sea posible hay que intentar mantener la longitud de las líneas por debajo de los ochenta caracteres.

Codificación de caracteres

Todos los ebuilds deben usar la codificación de caracteres UTF-8.

Variables

En el script podemos ver algunas variables, éstas, son usadas por Portage para averiguar algunas cuestiones relacionadas con nuestros paquetes.

  • La variable DESCRIPTION fija una descripción corta del paquete y su utilidad.
  • La variable HOMEPAGE es un link a la página original del proyecto de la aplicación.
  • La variable LICENSE se usa para definir bajo que tipo de licencia se encuentra el paquete.
  • La variable SRC_URI le indica a Portage de donde puede descargar el código fuente original. La variable ${PV} en la dirección es una variable especial de solo lectura fijada por Portage que le indica la versión del paquete sin información de revisiones.
  • La variable KEYWORDS define arquitecturas sobre las que se ha probado este paquete.

Funcion de construcción

La función de construcción del paquete es la llamada src_compile. El sistema Portage llama a esta función cuando quiere compilar el paquete. La función econf es un wrapper para la llamada a ./configure y emake es un wrapper para (si, lo has adivinado) la llamada a make. Si algo sale mal durante la llamada a make con || die nos estamos asegurando de que la ejecución de Portage terminará si por alguna razón sucede algún error.

La función que instalará nuestro paquete es (efectivamente) src_install que es llamada por Portage cuando quiere "instalar el paquete. Realmente esta función instala el paquete en un directorio especial especificado por la variable ${D} donde se instala de forma provisional antes de ser instalado al sistema de archivos real, es lo que se llama una caja de arena (Sandbox).

La función dodoc son funciones auxiliares de ayuda que sirven para instalar documentación en el directorio /usr/share/doc. Existen muchas funciones auxiliares de ayuda que el sistema Portage nos ofrece para utilizar en nuestros ebuilds con infinidad de aplicaciones.

Dependencias

Obviamente, hay paquetes que dependen de otros. Para informar a Portage de que un paquete tiene dependencias se utilizan las variables DEPEND y RDEPEND. La primera le dice a Portage cuales son las dependencias necesarias para el paquete en tiempo de compilación, y la segunda en tiempo de ejecución. Como por regla general, las dependencias de un paquete en tiempo de ejecución son las mismas que en tiempo de compilación, es habitual encontrar bloques como este en los ebuilds:

DEPEND="sys-devel/binutils
             sys-devel/bison"
RDEPEND="${DEPEND}"

Parches

Es también habitual que a los paquetes se les aplique parches de seguridad o de cualquier otro tipo antes de su etapa de compilación. Esto es realizado por la funcion src_unpack que a su vez llama a la función auxiliar de ayuda epatch que se encargará de aplicar los parches que encuentre (por regla general) en el directorio files del ebuild. Para poder utilizar la función auxiliar epatch, debemos de incluir una librería del sistema Portage llamada eutils. Las librerías en Portage se llaman eclass y se incluyen usando la palabra clave inherit.

inherit eutils
...
src_unpack() {
    unpack ${A}
    cd "${S}"
    epatch "${FILESDIR}"/${P}-cosamala.patch \
        "${FILESDIR}"/${P}-arreglo_bugs_a_mansalva.patch
}

La variable ${FILESDIR}/${P}-cosamala.patch se refiere al archivo vim-7.3.75-cosamala.patch que debe encontrarse en el directorio files. Aunque es habitual encontrar todos los parches de un paquete en este tipo de directorios, las reglas de empaquetado de Gentoo advierten que los parches muy grandes deben de ser descargados de un mirror de parches y aplicarlos después de descomprimirlos.

Flags USE

Todo aquel o aquella que haya trabajado con Gentoo conocerá las directivas USE. Dichas directivas sirven para indicarle a Portage que un paquete debe de incluir tal o cual feature. Por ejemplo, para compilar el paquete dev-db/mongodb con soporte para v8 debemos usar una directiva USE al invocar a emerge en la linea de comandos.

Estos flags están también definidos en el archivo ebuild del paquete y se definen con la variable IUSE:

IUSE="v8"

En próximas entradas entraremos en más detalle sobre el desarrollo de paquetes para Gentoo y el sistema Portage. De momento, si quieres ver ejemplos reales de archivos ebuild, no dudes en echarle un ojo a mi repositorio personal de ebuilds en mi Github.


Más Información | Manual de Ebuild, Gentoo Ebuild Howto

Temas
Publicidad
Comentarios cerrados
Publicidad
Publicidad
Inicio
Inicio

Ver más artículos