Guía de comprobaciones para los Portes

Index

• Introducción
• Cómo
• Primeros pasos
• Pruebas
• Comentarios
• Más verificaciones

Introducción

El árbol de portes es una gran pieza de trabajo que permite que los usuarios de OpenBSD puedan utilizar programas de terceros sin tener que aplicar parches, configurarlos, ni instalar cada uno de ellos de forma individual. Esta tarea la realiza un grupo de voluntarios que pasan su tiempo portando, comprobando y verificando aplicaciones en todo el abanico de plataformas de OpenBSD. Muchas personas creen que no pueden ayudar en este proceso debido a que no disponen de los conocimientos necesarios; esto no es cierto, pueden ayudar a que la tarea de los portadores se realice de forma más rápida y eficiente.

Cómo

Comprobando y verificando el funcionamiento de los nuevos portes que se envíen a la lista de correo de portes. De este modo se puede reducir el tiempo de entrega e incrementar la cantidad de portes que se entreguen (¡muchos portes no llegan a entregarse porque no han sido comprobados!).

Primeros pasos

La creación de nuevos portes se lleva a cabo sobre la versión de desarrollo del sistema (OpenBSD-current); no es posible garantizar el correcto funcionamiento de estos nuevos portes en otras versiones. Esto implica que para poder realizar pruebas antes es necesario actualizar el árbol del sistema y de los portes a la versión de desarrollo (las instrucciones para hacerlo se encuentran en la página de anoncvs y en el documento sobre Actualización de las preguntas frecuentes de OpenBSD). También es recomendable estar suscrito en la lista de correo ports-changes. En esta lista se notifican los nuevos portes o los actualizados, y cualquier otro cambio en el árbol de portes.

Pruebas

Los envíos de portes a las listas de correo son de dos tipos: portes nuevos y actualizaciones. Los nuevos suelen enviarse como archivos comprimidos adjuntos al mensaje o simplemente indicando una dirección de Internet en la que se encuentren. Una buena práctica es la de extraerlos en un directorio /usr/ports/misportes/ y probarlos desde ese directorio. Las actualizaciones suelen ser un fichero tipo diff que contiene las diferencias entre el porte actualizado y el que hay en el árbol de portes de desarrollo (ports-current). En este caso es recomendable copiar el porte en el directorio misportes/ y aplicarle el fichero .diff para evitar errores en el árbol de portes.

Es necesario componer el porte paso a paso para verificar que todos los objetivos se alcancen de forma correcta (véase ports(7)):

• fetch
  • Verifica que los ficheros de distribución (distfile) que se hayan bajado sean correctos. Hay que comprobar que todos los MASTER_SITES que se especifican sean válidos.
• checksum
  • Verifica que los ficheros de distribución (distfile) concuerden con las sumas de comprobación registradas en el fichero distinfo.
• extract
  • Cada uno de los ficheros de distribución debería instalar cualquier programa del que dependan (como bzip2) de antemano.
• patch
  • El resultado de aplicar un parche debe ser limpio, sin que produzca ningún error ni aviso.
  • No debe quedar ningún fichero .orig en el directorio patches.
  • Otro error común es el de incluir etiquetas de RCS en un parche; esto produce un error cuando se envía el porte al repositorio y se expande la etiqueta de RCS.
• configure
  • Comprueba que los guiones configure detecten correctamente las funcionalidades en la plataforma correspondiente.
  • GNU libtool es notable por sus 'funcionalidades' no deseables en OpenBSD; hay que asegurarse de que el porte utiliza una versión reciente que genere las bibliotecas correctas para la arquitectura de la que se trate.
  • El guión configure no debería detectar aplicaciones que ya se encuentren en el sistema sin que se hayan indicado de modo explícito como dependencias en el porte.
• build
  • Comprueba errores de compilación y avisos sospechosos.
  • Alerta sobre problemas con tmpnam(3) que deberían ser resueltos usando mkstemp(3).
  • Intenta configurar la variable SEPARATE_BUILD con el valor 'concurrent' y comprueba que la compilación aún funcione.
  • Se asegura que las dependencias de GNU make sean realmente necesarias.
• regress
  • Verifica errores (los resultados en blanco significan que están bien).
• fake
  • Este objetivo instala la aplicación en un directorio de trabajo falso, para asegurarse de que todos los ficheros se puedan empaquetar fácilmente sin que afecten al sistema base.
  • El porte nunca debe instalar ficheros fueras del directorio falso (como puede ser /usr/local).
  • En algunas ocasiones, GNU libtool tiene problemas re-enlazando bibliotecas durante el proceso falso en algunas arquitecturas.
• package
  • La creación del paquete puede romperse si pkg/PLIST* y/o pkg/PFRAG* son erróneos.
• install
  • Los paquetes deberían instalar todos los ficheros que aparecen en sus listas de empaquetamiento y con los permisos correctos. Hay que tener un cuidado especial con los ficheros que tengan activados los bits setuid.
  • Es importante asegurarse de que el guión de ejecución INSTALL funcione correctamente, y que no sobreescriba ningún fichero de /etc.
• deinstall
  • Esto debería eliminar todos los ficheros instalados por el paquete, excepto los que se instalen en /etc.
  • Es importante asegurarse de que el guión de ejecución DEINSTALL funcione correctamente.

Los ficheros pkg/ sobrantes, como DESCR y MESSAGE, deberían pasar una comprobación para la corrección de errores gramaticales y de estilo. Los párrafos se deben formatear usando fmt(1) y envolver a un máximo de 70 caracteres por línea.

Comentarios

Lo más importante viene a continuación de las comprobaciones: los comentarios. Hay que añadir comentarios al porte aunque éste funcione bien. Si recibimos diez mensajes en los que los usuarios nos confirman que el porte funciona bien en varias arquitecturas diferentes, entonces el proceso de entrega será más rápido. Si no funcionara bien, entonces hay que dar algo de información sobre los errores. Hay algunas herramientas que pueden ayudar en esta tarea, como portslogger, que redirecciona la salida a un fichero de registro (log file).

Ejemplo:

    # make install 2>&1 | /usr/ports/infrastructure/build/portslogger .

Esto redireccionará la salida a un fichero de registro ubicado en el directorio actual.

Más verificaciones

Buscar errores de escritura, enlaces incorrectos, variables inútiles o no existentes, licencias correctas, etc. en el fichero Makefile del porte. Quienes tengan más experiencia pueden comprobar otros objetivos como lib-depends-check, examinando parches y produciendo ficheros diferenciales (diff files) para la corrección de errores, añadiendo «sabores», u otras mejoras.

Estos ficheros .diff se deben crear con las opciones -uNr --exclude=CVS. También se puede usar cvs diff -uN para generar parches contra el repositorio de CVS.