Build Service/Guía básica
|
¡Este artículo necesita atención! Este artículo no cumple los estándares esperados en la Wiki de openSUSE. |
 |
Este documento debería proporcionar una visión general del servicio «Build Service» y un tutorial acerca de cómo construir paquetes para distintas distribuciones con esta gran herramienta. Intentaremos mostrar todas las acciones sobre una aplicación de ejemplo para que pueda seguir los pasos para producir sus propios paquetes. |
Requisitos previos
Deberá tener nociones generales acerca de RPMs y cómo se crean (consulte también los convenios de empaquetado de SUSE) o, si no, acerca de algún otro sistema de empaquetado soportado como dpkg. Este documento no pretende ser un sustituto de la documentación de empaquetado.
Debería estar familiarizado con el entorno de código fuente que su proyecto utiliza para su paquete. Build Service es capaz de evitar y «rodear» algunos errores habituales y, esperamos, le alertará sobre algunos problemas en su código fuente mostrando archivos de registro y errores de construcción. Existe una lista de correo buildservice-mailinglist que será una fuente de ayuda y consejos. Sin embargo las decisiones acerca de qué parches aplicar, qué argumentos de compilación utilizar, etc. dependen completamenente de usted.
Requisitos
Para poder hacer uso de Build Service primero necesitará una cuenta para acceder. ;-)
Su cuenta de buildservice es la misma que la del wiki y bugzilla. Utilice el enlace en la parte superior de esta página para crearla si no dispone de una.
Después de crear su cuenta de wiki/bugzilla, diríjase a http://build.opensuse.org/ y acceda allí. Al entrar por primera vez deberá rellenar un formulario de preguntas y explicar por qué quiere una cuenta y qué desea empaquetar. Luego tendrá que esperar hasta que se acepte su solicitud. Mientras espera puede suscribirse a la lista de correo opensuse-buildservice y hacer una breve presentación. Simplemente indíquenos su nombre y cuéntenos algo acerca del proyecto que desea crear y mantener (alguna mención acerca de sus habilidades de empaquetado también serán bienvenidas).
Si quiere probar o construir sus paquetes en casa (que siempre es una buena idea) debería echar un vistazo al Tutorial SUSE Build para familiarizarse con los requisitos de un entorno de construcción local.
Terminología
Build Service contiene proyectos (puede ver una lista de todos ellos -necesita login-). Cada proyecto contiene los recursos necesarios para construir uno o más paquetes (p.ej.: RPMs). Estos recursos incluyen archivos de código fuente, archivos de parches, archivos spec, etc. El resultado de un proyecto es uno o más repositorios. Un repositorio es un viejo y familiar concepto: simplemente un conjunto de RPMs organizados en una jerarquía de directorios junto con algunos archivos de índices y metadatos que facilitan el trabajo a herramientas como zypper, que buscan y resuelven dependencias. Los repositorios resultantes de un proyecto se corresponden con las distintas versiones de sistemas operativos como openSuSE 10.3, etc.
En cuanto a los proyectos existentes, hay proyectos SUSE «oficiales» que construyen los RPMs proporcionados en las distribuciones estándar de SUSE. el proyecto «factory» es el proyecto de «trabajo en progreso» que se convertirá en la siguiente versión de SUSE. También hay muchos otros projectos específicos como Apache y network:telephony. Además, cada usuario tiene su propio proyecto «de andar por casa» llamado home:username.
Los paquetes RPM tienden a tener muchas dependencias de otros RPMs, y a menudo, estos RPMs provienen de otros proyectos dentro de Build Service. Esto tiene dos repercusiones importantes.
En primer lugar, si su paquete depende de otro a la hora de ejecutarse («Requires»),la mayoría de las veces también dependerá de él en el momento de la compilación («Build-Requires»). Build Service no busca, encuentra y construye las dependencias automáticamente (más allá de las incluidas en la distribución estándar para la que está empaquetando). Por lo tanto, deberá indicarle de alguna forma dónde encontrar los paquetes de dependencia.
En segundo lugar, un buen objetivo para un repositorio es que esté transitivamente cerrado, es decir, que cualquier dependencia de un paquete en el repositorio también esté en ese repositorio (excepto los paquetes estándar de la distribución). Esto le facilita la vida a la gente que instala los RPMs proporcionados por su proyecto. Pero esto no es obligatorio; los usuarios siempre podrán encontrar estas dependencias a mano mediante la interfaz de búsqueda.
Build Service proporciona varias formas distintas para facilitar la gestión de las dependencias.
En primer lugar puede añadir los paquetes de las dependencias directamente a su repositorio. Esta es la opción correcta si ningún otro proyecto construye el paquete que necesita. Sin embargo, habitualmente ya hay algún proyecto que está construyendo el paquete de dependencia. ¿Entonces, cómo puede reutilizar el trabajo ya hecho?
La segunda opción es enlazar el repositorio del otro proyecto al suyo. Esto se hace editando los metadatos de su proyecto. Lo que se hace es añadir el otro repositorio a la lista de repositorios en los que Build Service buscará las dependencias «Build-Requires» a la hora de compilar. Esto permitirá que la construcción de su paquete sea satisfactoria, lo que resuelve el primer problema, pero no el segundo, el objetivo de estar «transitivamente cerrado»; los usuarios tendrán que buscar los paquetes de dependencia ellos mismos. No obstante será una buena elección si varias dependencias de su proyecto están en otro y los usuarios probablemente utilicen ambos de todos modos.
La tercera opción se denomina enlazar («linking» en inglés) y es una forma de permitir que su proyecto reutilice un paquete ya existente en otro proyecto. Cuando enlaza otro paquete en su proyecto, se podrán construir los paquetes dependientes y el paquete también aparecerá en el repositorio de su proyecto, solucionando ambos problemas sin duplicar el trabajo.
Hay dos formas de enlazar: link y aggregate.Mediante link podrá, opcionalmente, modificar la forma en la que se construye el paquete. Su versión del paquete RPM tendrá un número distinto de «build» que el del proyecto original. Esto podría causar confusión a los usuarios. En realidad estará construyendo una versión distinta de un paquete del mismo nombre.
A no ser que necesite modificar el paquete de dependencia, debería utilizar aggregate en vez de link. Cuando utiliza aggregate está realizando un enlace de «sólo lectura». El paquete no se construirá dentro de su proyecto, al contrario, el paquete ya construido se copia en su proyecto desde el proyecto original. Así, el mismo RPM (con el mismo número de «build») aparecerá en ambos proyectos. Hay menos confusión para el usuario porque los RPMs son esencialmente el mismo.
Build Service detecta cambios en los paquetes enlazados y desencadena reconstrucciones de paquetes que dependen de ellos.
Flujo de trabajo
Los siguientes pasos son un esquema de un flujo de trabajo habitual para la construcción de un proyecto y la adición de paquetes. Por supuesto que un ejemplo de la vida real fallaría en alguno de los pasos y tendría que repetirlo hasta que funcione correctamente. Este esquema simplemente le dará una visión global de lo que intentamos hacer.
Mostraremos dos formas diferentes:
- el modo Cliente web
- el modo Cliente de Línea de comandos (utilizaremos osc para nuestro ejemplo)
Primer paso - Acceso
Si ya dispone de su cuenta en Build Service, este será el paso más sencillo.
- Cliente web: abra http://build.opensuse.org/ y pulse en uno de los enlaces «List of All Projects» o «Watched Projects». Se le pedirá su nombre de usuario y contraseña de openSUSE Build Service. A continuación verá la lista de proyectos y en la esquina superior derecha encontrará un enlace a su «Home Project». Siga ese enlace.
- Línea de comandos: en primer lugar debe instalar el cliente de línea de comandos en su equipo local. Encontrará los paquetes de osc para varias distribuciones en el repositorio de descarga de software de openSUSE-Tools (sí: esto también es un projecto de Build Service). Utilice su gestor de paquetes preferido para instalar el paquete osc. Nota: para SUSE Linux 9.3 o anteriores necesitará además los paquetes python-elementtree y python-urlgrabber de aquí.
Una vez hecho esto, acceda al directorio que desea utilizar para los archivos de sus proyectos. En este momento cualquier persona familiarizada con SVN se sentirá «como en casa»: intente hacer «checkout» de su proyecto personal («Home project») con el comando
osc checkout home:<username>
(reemplace <username> con su nombre de usuario). Se le pedirá que introduzca su nombre de usuario y contraseña, luego osc intentará obtener los paquetes de su proyecto personal y crear un direcotrio nuevo llamado home:<username>. Podrá editar sus preferencias en el archivo ~/.oscrc.
Segundo paso - Crear y subir paquetes
No es realmente necesario empezar en el proyecto personal puesto que también puede subir paquetes directamente a un proyecto existente, pero es un buen punto de partida y no se debería usar el proyecto personal de otro usuario como dependencia de construcción. Utilice, pues, su proyecto personal como «patio de recreo» para probar paquetes que serán transferidos a otros proyectos si todo va bien.
- Cliente web: Pulse en el enlace [Add Package]. Deberá rellenar los siguientes tres campos de texto: «Name», «Title» y «Description». Utilice el nombre del paquete como «Name», un resumen del paquete como «Title» y la descripción como «Description».
- A continuación pulse en el enlace [Add File] para añadir los archivos de su paquete. Necesitará subir el código fuente y por lo menos un archivo spec.
- ACLARACIÓN ¿Qué se necesita para paquetes debian?
- Línea de comandos:
osc meta pkg -e home:<username> <packagename>
osc abrirá un plantilla xml en su editor preferido (basándose en la variable de entorno EDITOR) y podrá añadir los mismos datos mencionados más arriba (Name, Title y Description).
Ahora ejecute
osc up
y obtendrá un nuevo directorio con el nombre del paquete nuevo. Para añadir archivos desde la línea de comandos simplemente cambie al nuevo directorio (con «cd») y ejecute
osc add *
esto marcará a los archivos de ese directorio para el siguiente «submit». Para enviar los archivos ejecute
osc commit
Tercer paso - Añadir repositorios
Vuelva a su página personal de OBS (OpenSUSE Build Service). Ahora deberá decidir para los repositorios de qué distribución construirá su paquete.
- Cliente web: pulse en [Add Repository] y elija una de las distribuciones y arquitecturas disponibles.
- Línea de comandos: primero obtenga una lista de los repositorios disponibles
osc ls
a continuación edite los metadatos de su proyecto
osc meta prj -e home:<username>
y añada los repositorios así:
<repository name="SUSE_Linux_Factory"> <path project="openSUSE:Factory" repository="standard" /> <arch>x86_64</arch> <arch>i586</arch> </repository>
Nota: el atributo repository="standard" solo es para extensiones futuras (bifurcaciones de un repositorio).
Cuarto paso: Construir el paquete
Normalmente su paquete queda programado para construcción después de que haya sido enviado o después de que haya cambiado algún archivo. Si se reconstruye una dependencia, su paquete también será reconstruido. También podrá desencadenar una reconstrucción manualmente si lo necesita (pero no haga esto muy a menudo para que los otros paquetes tengan su oportunidad).
Construir el paquete en local
En ocasiones puede resultar más rápido construir su paquete en su equipo local en lugar de esperar por los resultados de buildservice. osc permite la construcción local de su paquete, siempre que su hardware lo permita también (en x86_64 puede construir para i586 y x86_64, en i586 solamente para i586).
osc build <plataforma> <arq> <archivospec> [--clean|--noinit]
Si inicia la construcción como usuario normal (¡buena idea!) se le pedirá la contraseña de «root» de su equipo local. Puede evitarlo si añade su usuario al archivo /etc/sudoers y edita su archivo ~/.oscrc:
su-wrapper = sudo
y con visudo añada la línea (como root):
<su cuenta login> ALL = NOPASSWD: /usr/bin/build
a la configuración de sudo (por supuesto sin los signos «<» y «>»). osc se conectará al servidor-repositorio y descargará todos los RPMs necesarios utilizando /var/tmp/osbuild-packagecache/<plataforma>/<repositorio>/<arq> como directorio «caché». (Por lo que, si ya tiene un repositorio completo puede enlazar los RPMs de este directorio para evitar un inmenso tráfico de red).
Por ejemplo para el repositorio de openSUSE_10.2 puede utilizar la iso del DVD comercial así:
mount openSUSE-10.2.iso /mnt/openSUSE-10.2 -o loop mkdir -p /var/tmp/osbuild-packagecache/openSUSE\:10.2 ln -s /mnt/openSUSE-10.2/suse/* /var/tmp/osbuild-packagecache/openSUSE:10.2/standard
Esto le proporcionará los repositorios para x86 además de para x86_64
Ahora podrá construir paquetes en local así:
osc build openSUSE_10.2 i586 beryl-core-snapshot.spec
osc creará un entorno chroot en /var/tmp/osc-build-root/ e iniciará la construcción de su paquete. Si solamente ha hecho pequeños cambios puede evitar la nueva creación del entorno de construcción mediante la opción --noinit. Si sospecha que su entorno chroot está corrompido puede desencadenar una reconstrucción completa con la opción --clean.
Después de que se hayan construido sus paquetes en este entorno chroot, encontrará los paquetes resultantes en /var/tmp/osc-build-root/usr/src/packages/RPMS/.
El archivo de registro completo de su construcción local está almacenado en /var/tmp/osc-build-root/.build.log.
Construir en build service
Construir el paquete en build service es más fácil que hacerlo en local, pero quizás tarde más tiempo.
- Cliente web: Si desea desencadenar una reconstrucción manual, pulse en [Trigger Rebuild] en la parte inferior de la página de paquetes.
- Línea de comandos: con los parámetros opcionales <repo> y <arq> se puede limitar la reconstrucción a un repositorio o arquitectura en concreto.
osc rebuildpac <proyecto> <paquete> [<repo> [<arq>]]
Si quiere escribir su propio archivo .spec debería leer el HOWTO correspondiente. A continuación deberá subirlo.
|
Normalmente NO es necesario iniciar reconstrucciones de este modo porque principalmente ocurren de forma completamente automática, desencadenas por subidas de código. Concretamente, el orden en que se construyen los paquetes lo gestiona build service. |
|
Quinto paso: Comprobar los archivos de registro
Build service genera un gran archivo de registro por cada construcción de un paquete.
- Cliente web: pulse en el enlace [Build Log] en la vista de paquetes.
- Línea de comandos: dispone de varias opciones dependiendo de sus necesidades; (
packagedires opcional si ya está en su directorio de paquetes):
osc prjresults [packagedir]
Muestra el conjunto de resultados de construcción de un proyecto completo. O puede hacer:
osc results [packagedir]
Muestra los resultados de construcción de un solo paquete.
osc buildlog <platform> <arch>
Muestra el archivo de registro de un paquete (debe estar dentro de un directorio de paquetes).
Crear patrones
Los patrones son archivos que contienen una lista de paquetes junto con una descripción de para qué sirven (en el futuro Build Service exportará patrones a los repositorios para que sean visibles en YaST). Además, Build Service crea archivos .ymp para cada patrón de repositorio generado. Estos archivos .ymp se pueden utilizar para que los usuarios puedan instalar con un solo clic: One Click Install.
En resumen, los patrones son útiles para instalar un conjunto de programas para una necesidad concreta sin crear dependencias entre paquetes.
Se pueden enviar patrones directamente mediante el api o con osc:
- para abrir un patrón en $EDITOR (y crearlo si no existe ya)
osc meta pattern -e <project> <pattern>
- para enumerar patrones existentes
osc meta pattern <project>
- obtener un patrón existente
osc meta pattern <project> <pattern>
- También puede enviar un archivo existente así:
osc meta pattern --file <local_file> <project> <pattern>
Para probarlo: pulsando en el archivo .ymp en Konqueror debería lanzar el instalador, si no tiene instalado Konqueror puede intentar lanzándolo desde una shell como usuario normal:
/sbin/yast2 MetaPackageHandler http://download.opensuse.org/repositories/<project>/<SUSE_Factory or openSUSE_10.2>/<pattern>.ymp
El siguiente archivo es un archivo de patrón de ejemplo del proyecto KDE:KDE4. Puede ver el archivo .ymp generado aquí.
<pattern
xmlns="http://novell.com/package/metadata/suse/pattern"
xmlns:rpm="http://linux.duke.edu/metadata/rpm"
>
<name>KDE 4 Games</name>
<summary>KDE 4 Games</summary>
<description>A number of games for KDE 4.</description>
<uservisible/>
<category lang="en">Desktop Functions</category>
<rpm:recommends>
<rpm:entry name="kde4-kpat"/>
<rpm:entry name="kde4-kmahjongg"/>
<rpm:entry name="kde4-kmines"/>
<rpm:entry name="kde4-kreversi"/>
<rpm:entry name="kde4-ksudoku"/>
</rpm:recommends>
<rpm:suggests>
<rpm:entry name="kde4-katomic"/>
<rpm:entry name="kde4-kbattleship"/>
<rpm:entry name="kde4-ksquares"/>
<rpm:entry name="kde4-bovo"/>
<rpm:entry name="kde4-kiriki"/>
<rpm:entry name="kde4-kwin4"/>
<rpm:entry name="kde4-kolf"/>
<rpm:entry name="kde4-klines"/>
<rpm:entry name="kde4-ksame"/>
<rpm:entry name="kde4-lskat"/>
<rpm:entry name="kde4-kgoldrunner"/>
<rpm:entry name="kde4-kblackbox"/>
<rpm:entry name="kde4-kbounce"/>
<rpm:entry name="kde4-ktuberling"/>
<rpm:entry name="kde4-knetwalk"/>
<rpm:entry name="kde4-kjumpingcube"/>
<rpm:entry name="kde4-kspaceduel"/>
<rpm:entry name="kde4-konquest"/>
<rpm:entry name="kde4-kshisen"/>
</rpm:suggests>
</pattern>
Algunas descripciones de etiquetas:
| Etiqueta | Descripción |
|---|---|
<rpm:requires> <rpm:entry name="example" /> </rpm:requires> |
Requires RPM example: este paquete debe estar instalado, si no el patrón no se cumple. |
<rpm:recommends> <rpm:entry name="example" /> </rpm:recommends> |
Recommends RPM example: si está disponible y todas las dependencias de este paquete se cumplen, se instalaría el paquete. Si el paquete no está disponible no habrá mensajes de error. Si las dependencias de paquete no se cumplen el paquete estaría visible pero no instalado. |
<rpm:suggests> <rpm:entry name="example" /> </rpm:suggests> |
Suggests RPM example: se mostraría en el paquete pero no se instalaría de forma predeterminada. |