Información sobre los portes de OpenBSD

Diferencias importantes con otros proyectos BSD

NetBSD usa el término ports ("portes") para definir a las diferentes arquitecturas en las que funciona el sistema operativo. Su estructura de portes se llama packages ("paquetes").

Soporte adicional

build/resolve-lib

invocado vía make lib-depends-check, para verificar dependencias de bibliotecas dinámicas (compartidas).

build/update-patches

invocado vía make update-patches, que debe usarse siempre para regenerar los parches.

install/make-plist

invocado vía make update-plist. Se ocupa de las cuestiones más importantes que afectan a la creación de listas de empaquetado. Las listas de empaquetado de OpenBSD son significativamente diferentes de los de otras proyectos BSD, en parte debido a que las herramientas de empaquetado han sido completamente reescritas.

Temas genéricos de infraestructura

En OpenBSD, 'make' tiene soporte para ${VAR:U} y ${VAR:L} para transformar el valor de una variable a mayúsculas o minúsculas. De acuerdo con esto, las comprobaciones de 'make' se deberían codificar de forma independiente del caso, v.g.:

	.if ${NEED_XXX:L} == "yes"
	do stuff if yes
	.else
	do other stuff
	.endif

En teoría, todas las variables booleanas reconocidas por bsd.port.mk deben siempre definirse, de modo que al final código como defined(USE_FOO) no deba ser necesario y ${USE_FOO:L} != "no" debería funcionar.

El fichero principal bsd.port.mk ha sido fuertemente adaptado y se han solucionado algunos problemas. En particular, está preparado para ir paralelo a 'make'. La funcionalidad scripts/{pre,do,post}-* se ha perdido en el proceso. Para reemplazar esta funcionalidad, invoque el guión ("script") a mano desde el fichero Makefile.

Usar make correctamente

Note que si invoca 'make' como make VAR=value, la asignación anulará cualquier valor que VAR obtenga de Makefile. Por ello, muchos parches para Makefile no son necesarios, es mucho mejor configurar correctamente MAKE_FLAGS para disminuir la carga del mantenimiento.

Obtener el código fuente

Existen dos tipos de archivos de fuentes: DISTFILES y PATCHFILES. OpenBSD los procesa de un modo uniforme y, de modo predeterminado, lo saca todo de MASTER_SITES. No hay PATCH_SITES ni PATCH_SITES_SUBDIR.

Si todos los parches que se bajaran no provinieran del mismo grupo de sitios, OpenBSD permitiría las extensiones filename:0 a filename:9, en cuyo caso usaría MASTER_SITES0 hasta MASTER_SITES9 para bajar el fichero.

Es posible que algunas arquitecturas necesiten ficheros distfiles específicos. En el pasado, esto ha causado problemas en donde ha sido preciso replicar ("mirror") distfiles. OpenBSD dispone de soporte para un tercer grupo de ficheros: SUPDISTFILES. éstos serán considerados sólo para generar sumas de comprobación y réplicas. Nótese que es posible que SUPDISTFILES coincida en parte con DISTFILES o PATCHFILES. Por ejemplo:

	DISTFILES=foo-1.0.tgz
	.if ${ARCH} == "i386"
	DISTFILES+=foo-i386.tgz
	.elif ${ARCHI} == "sparc"
	DISTFILES+=foo-sparc.tgz
	.endif
	SUPDISTFILES=foo-i386.tgz foo-sparc.tgz

La infraestructura de trabajo WRKDIR

No queremos portes que usen NO_WRKDIR. Todos los portes de OpenBSD deben tener un directorio de trabajo. Los detalles sobre el nombre de estos directorios de trabajo no tienen porqué ser la preocupación de un «portador». Si necesita averiguar uno de estos nombres, mire en el fichero Makefile: cd that_ports_dir && make show=WRKDIR le dará una idea sobre el WRKDIR (directorio de trabajo) de ese porte.

La principal razón detrás de esa prohibición es que en OpenBSD, bsd.port.mk actúa como un fichero Makefile real, con dependencias. El paso fethc depende de los distfiles y patchfiles, y el resto de los pasos dependen de ficheros reales ubicados en el directorio de trabajo ("cookies"), así que no pueden existir sin un directorio de trabajo.

EXTRACT_ONLY=

y lleve a cabo la extracción en post-extract.

WRKDIR

Directorio de trabajo del porte, en donde pone sus propias cookies.

WRKDIST

Subdirectorio de WRKDIR, en donde el porte se desempaqueta. También es el directorio base para parches. Otros BSD no tienen en la actualidad la distinción WRKDIST/WRKSRC, y sólo tienen WRKSRC.

WRKSRC

Subdirectorio de WRKDIST, en donde están ubicados los fuentes.

WRKBUILD

Subdirectorio de WRKDIR, en donde tendrá lugar la configuración y compilación del porte. Otros BSD no tienen la distinción WRKBUILD/WRKSRC. Los programas que se basen en autoconf (la mayoría) pueden generalmente configurar SEPARATE_BUILD para dejar que la compilación del porte sea en un WRKBUILD diferente a WRKSRC.

WRKCONF

Subdirectorio de WRKDIR donde los scripts configure deben ejecutarse. De forma predeterminada es WRKBUILD, lo que es correcto el 99% del tiempo.

WRKINST

Directorio en donde se instalará el porte antes de ser empaquetado (ver «Simulación de portes», más abajo).

Nota: NO_WRKSUBDIR ha sido eliminado; su funcionalidad se puede obtener configurando WRKDIST=$(WRKDIR).

Simulación de portes

Introducción

Después de que una compilación se ha completado, otros BSD proceden con la instalación del porte y a continuación compilan un paquete con el porte instalado. En lugar de eso, OpenBSD usa una instalación simulada.

• Un porte OpenBSD se configura y compila normalmente (v.g., para instalarse en PREFIX, que suele ser /usr/local).
• Pero se le indica que se instale en otra parte, en WRKINST, que suele ser un subdirectorio de WRKDIR.
• Entonces se empaqueta la instalación ficticia, usando la opción -B de pkg_create.
• Finalmente, el paquete resultante puede ser instalado usando pkg_add.

Ventajas

• Para quien construye el paquete, esto significa que la mayoría de portes no tienen que ser instalados, lo que elimina un gran número de compromisos potenciales y desagrado general debido a portes mal instalados. También permite construir varios paquetes con conflictos entre sí en la misma máquina. Finalmente, permite construir un nuevo grupo de paquetes no probados sin tener que hacer una instalación correcta.
• Para quien construye un porte, simplifica enormemente la labor de encontrar problemas en listas de paquetes, ya que el área falsa de instalación se encuentra vacía antes de que sea instalado el porte. Además, si un porte instala demasiados ficheros, ya no es necesario retocar la instalación del porte: es suficiente con no grabar los ficheros extraños en la lista de empaquetado.
• Para el usuario final, mejora la calidad de los paquetes; ya que el porte final se instala usando pkg_add, el usuario final obtiene exactamente el mismo software que fue preparado en la máquina del portador.

Cómo hacerlo

Los objetivos invocados para make fake son los objetivos de instalación usuales, con la excepción de unas pocas diferencias:

• Se usa FAKE_FLAGS en lugar de MAKE_FLAGS. Por definición, FAKE_FLAGS configura DESTDIR=${WRKINST}.
• Se usa FAKE_TARGET en lugar de INSTALL_TARGET.
• Los fragmentos {pre,per,post}-instalación se invocan con TRUEPREFIX configurado a $(PREFIX), PREFIX configurado a $(WRKINST)$(PREFIX), y DESTDIR configurado a $(WRKINST).

Los portes que usen imake deberían funcionar tal cual, ya que los fragmentos imake están configurados para usar DESTDIR. De forma parecida, los portes recientes que usen GNU configure no deberían necesitar ningún cambio.

Otra técnica útil es un truco de `ligado tardío': configure los portes para usar un prefijo $(DESTDIR)/usr/local, de modo que el fichero Makefile resultante tenga

prefix=$(DESTDIR)/usr/local

configurado. Cuando el porte se compile, y puesto que DESTDIR está configurado a nada, se usará /usr/local y la falsa instalación pondrá todo en WRKINST/usr/local (v.g., para portes que usen GNU configure, utilice CONFIGURE_STYLE= gnu dest).

Dificultades

• Algunos portes son inconsistentes procesando sus DESTDIR: la mayoría de portes van bien con DESTDIR activado, excepto uno ó dos. Solucione el problema con parches.
• Lleve cuidado al distinguir entre la ubicación real en donde está instalado el porte, y la ubicación grabada en los ficheros de configuración del paquete. Es muy fácil saltarse esto, pero también es fácil de solucionar usando TRUEPREFIX.
• Siempre hay que retocar los enlaces simbólicos absolutos. Por suerte, bsd.port.mk se dará cuenta de los problemas en ese área.
• Unos pocos portes no quieren dejar $(DESTDIR) sólo durante la configuración. Se necesita un fragmento de postconfiguración que retoque todos los ficheros Makefile para añadir DESTDIR.
• En raras ocasiones, un porte se puede resistir a todos lo intentos razonables por usar FAKE. Una aproximación de fuerza bruta debería funcionar: use pre-fake para enlazar o copiar todo lo que el porte quiera encontrar en el área WRKINST, y entonces lleve a cabo la instalación bajo chroot.

Herramientas de empaquetado

Las herramientas de empaquetado conocen algunos tipos de fichero, y pueden hacer muchas cosas de forma automática: en la mayoría de los casos órdenes @exec o scripts INSTALL son innecesarios.
Tenga en cuenta que todos los scripts que no sean necesarios deben ser excluidos, ya que tienen problemas de escalabilidad. Es mucho más fácil de depurar una infraestructura simple de empaquetado que modificar cientos de scripts que generen nuevos problemas.
Por ejemplo:

• @exec ldconfig no es necesario, pues las bibliotecas compartidas están anotadas con @lib libfoo.so.1.0 y ldconfig es ejecutado cuando es necesario, y maneja chroot con elegancia.
• @exec install-info no es necesario, pues los ficheros de documentación son anotados con @info file.info. Se ocupa igualmente de multiples ficheros info, y elimina la necesidad de makeinfo --no-split.
• las fuentes se integran automáticamente gracias a @font y @fontdir.
• Los nuevos usuarios y grupos son manejados con @newuser y @newgroup en lugar de scripts de instalación. También son creados lo suficientemente pronto para que la extracción de paquete pueda usarse.
• Los ficheros de configuración son manejados por medio de @sample en lugar de scripts de instalación.

Diríjase a pkg_create(1) para obtener más detalles. En la mayoría de casos, make update-plist escribirá una muy buena aproximación de la lista de empaquetado completa, y se encargará de las mejoras de una versión a otra.

Sabores

Las opciones se han racionalizado como «sabores», para que la construcción de paquetes pueda ser consistente. Un porte con opciones debe configurar FLAVORS a la lista de todas las opciones que tengan sentido para ese porte (v.g., FLAVORS=foo bar zoinx), y entonces usar FLAVOR para verificar qué opciones han sido seleccionadas (v.g., FLAVOR=zoinx foo).
bsd.port.mk provee algo de soporte:

• PKGNAME se retoca para incluir opciones separadas por guiones (v.g., package-foo-zoinx).
• WRKDIR se retoca para que se puedan compilar sabores distintos de forma concurrente sin que colisionen.
• Las construcciones de la forma %%flavor%% activarán la inclusión de PFRAG.flavor. La construcción %%SHARED%% activa la inclusión de PFRAG.shared.
• bsd.port.subdir.mk entiende la extensión SUBDIR=directory,opt1,opt2 para decir «compila el porte en directorio con FLAVOR=opt1 opt2».

Comprobar que un sabor dado ha sido seleccionado es tan simple como:

.if ${FLAVOR:L:Mzoinx}