diff --git a/es_ES.ISO8859-1/books/handbook/ports/chapter.sgml b/es_ES.ISO8859-1/books/handbook/ports/chapter.sgml index 814a82ac73..e27e0d9a78 100755 --- a/es_ES.ISO8859-1/books/handbook/ports/chapter.sgml +++ b/es_ES.ISO8859-1/books/handbook/ports/chapter.sgml @@ -1,2091 +1,2091 @@ Instalando Aplicaciones: La colección de Ports Contribuido por &a.jraynard;. La colección de Ports de FreeBSD te permite compilar e instalar una gran cantidad de programas con el mínimo esfuerzo. Debido a las diferencias entre los estándars abiertos, conseguir que un programa funcione en una versión diferente de Unix puede ser tedioso y complicado, como debe saber todo aquel que lo haya intentado. Tendrás suerte si el programa que quieres compila limpiamente, instala todos los componentes donde debe instalarlos y funciona todo correctamente al primer intento. Algunas distribuciones de software han intentado solucionar este problema incluyendo unos scripts de configuración. Algunos de estos scripts son muy inteligentes, pero tienen tendencia a anunciar que tu sistema es algo que nunca has oido y hacen preguntas que suenan a un exámen final de programación en Unix. Afortunadamente, con la colección de Ports, todo el trabajo duro ya está hecho, y solo tienes que teclear el comando make install para tener un programa perfectamente instalado y en funcionamiento. ¿Porqué tener una Colección de Ports? El sistema base de FreeBSD incluye una gran variedad de herramientas y utilidades de sistema, pero muchos de los programas populares no están en la distribución base del sistema, por buenas razones: Programas con los que algunos usuarios no puede vivir sin ellos y otros usuarios ni los conocen, como cierto editor basado en Lisp. Programas demasiado especializados para ser incluidos en la distribución base del sistema (CAD, bases de datos, etc). Programas que se pueden incluir en la categoría “Tengo que mirarlo cuando tenga un rato libre” (algunos lenguajes, por ejemplo). Programas que son demasiado divertidos para ser incluidos en un sistema operativo serio como FreeBSD ;-) Por muchos programas que se incluyesen en el sistema base, la gente siempre quiere más, y se debe crear una línea de separación en algún momento (de otra manera, las distribuciones de FreeBSD serín enormes). Obviamente no sería razonable que cada usuario se portase manualmente sus programas favoritos (sin mencionar la enorme cantidad de trabajo duplicado), así que el proyecto FreeBSD ha usado un ingenioso sistema que mediante herramientas estándar permite automatizar todo el proceso. Esta es una excelente ilustración de como el “Unix way” trabaja en la prática combinando una serie de simples pero muy flexibles herramientas y consiguiendo algo muy potente. ¿Cómo funciona la Colección de Ports? Los programas en Internet se suelen distribuir como un tarball consistente en un Makefile y el código fuente del programa, incluyendo algunas instrucciones (las cuales no siempre son tan instructivas como debieras), y un script de configuración. El escenario habitual es que bajas el tarball vía FTP, lo extraes en algún directorio, lees las instrucciones, haces los cambios que parezcan necesarios, ejecutas el script de configuración y usas el programa make para compilar e instalar el programa desde el código fuente. Los ports de FreeBSD siguen usando el mecanismo del tarball, pero usan un esqueleto en el que guardan la información necesaria para que el programa funcione correctamente en FreeBSD. Los ports también tienen su propio y personalizado Makefile para practicamente todos los ports puedan ser compilados de la misma manera. Si miras el esqueleto de un port (ya sea en tu sistema FreeBSD o en el servidor FTP) y esperas encontrar todo tipo de combinaciones de ciencia avanzada, puede que te decepciones, ya que sólo encontrarás uno o dos ficheros y directorios de lo más habitual. (En un momento veremos como obtener un port). “¿Cómo es posible que esto pueda hacer algo? ” Oigo como lloras. “No hay código fuente!” Lo creas o no, gentil lector, todo quedará entendido (o eso espero). Veamos que pasa si intentamos instalar un port. He elegido el programa ElectricFence, una útil herramienta para desarrolladores, ya que el esqueleto es más claro que muchos otros. Si intentas ejecutar esto, necesitas estar como root. &prompt.root; cd /usr/ports/devel/ElectricFence &prompt.root; make install >> Checksum OK for ElectricFence-2.0.5.tar.gz. ===> Extracting for ElectricFence-2.0.5 ===> Patching for ElectricFence-2.0.5 ===> Applying FreeBSD patches for ElectricFence-2.0.5 ===> Configuring for ElectricFence-2.0.5 ===> Building for ElectricFence-2.0.5 [lots of compiler output...] ===> Installing for ElectricFence-2.0.5 ===> Warning: your umask is "0002". If this is not desired, set it to an appropriate value and install this port again by ``make reinstall''. install -c -o bin -g bin -m 444 /usr/ports/devel/ElectricFence/work/ElectricFence-2.0.5/libefence.a /usr/local/lib install -c -o bin -g bin -m 444 /usr/ports/devel/ElectricFence/work/ElectricFence-2.0.5/libefence.3 /usr/local/man/man3 ===> Compressing manual pages for ElectricFence-2.0.5 ===> Registering installation for ElectricFence-2.0.5 Para evitar confusiones, he borrado todas las líneas correspondientes a la compilación del programa. Si has realizado la instalación de este port, habrás obtenido algo así en pantalla: &prompt.root; make install >> ElectricFence-2.0.5.tar.gz doesn't seem to exist on this system. >> Attempting to fetch from ftp://ftp.doc.ic.ac.uk/Mirrors/sunsite.unc.edu/pub/Linux/devel/lang/c/. El programa make notifica que no tienes una copia en local del código fuente e intenta bajarlo por FTP. En el ejemplo, ya tenía el código en el ordenador, por lo que no ha sido necesario obtenerlo de Internet. Vayamos revisando que ha hecho el programa make Localizar el tarball con el código fuente. Si no está disponible localmente, intenta obtenerlo desde un servidor FTP. Ejecutar un test de checksum para asegurar que el tarball del código fuente es correcto. Extraer el tarball en un directorio temporal. Aplicar todos los parches necesarios para que el código fuente compile y funcione bajo FreeBSD. Ejecutar cualquier script de configuración requerido por el proceso de compillación, además de responder correctamente a cualquiera de las preguntas realizadas por éste. (Finalmente!) Compilar el código. Instalar los ejecutables del programa y otros archivos de soporte, páginas man, etc, bajo la jerarquía /usr/local, donde no se mezclarán con los programas de sistema. Esto también asegura que todos los ports que instales estarán en el mismo lugar, evitando que queden repartidos por diferentes lugares del disco. Registrar la instalación en una base de datos. Esto significa que, si no te gusta el programa, puedes borrar todos sus programas y archivos de tu sistema. Vuelve a mirar la salida del programa make antes mostrada e intenta localizar los pasos descritos. Y si no estabas impresionado antes, deberías estarlo ahora. Obteniendo un Port de FreeBSD Hay dos maneras de obtener un port de FreeBSD para un programa. Uno requiere el CDROM de FreeBSD, y el otro requiere una conexión a Internet. Compilar los PORTS desde CDROM Asumiendo que tu CDROM de FreeBSD está en el lector y montado en /cdrom (y must estar montado en /cdrom), deberís poder compilar toda la colección de ports sin problemas, ya que ésta encontraría los tarballs en /cdrom/ports/distfiles/ (si existen allí) en lugar de obtenerlos de Internet. Otra manera de hacer esto, si sólo quieres usar los esqueletos del CDROM, es poner la variables del fichero /etc/make.conf de la siguiente manera: PORTSDIR= /cdrom/ports DISTDIR= /tmp/distfiles WRKDIRPREFIX= /tmp Substituye /tmp por cualquier directorio en el que tengas suficiente espacio. Entonces, entra en el subdirectorio apropiado bajo /cdrom/ports y teclea make install como hasta ahora. WRKDIRPREFIX hará que el port sea compilado bajo /tmp/cdrom/ports; por ejemplo, games/oneko será compilado bajo /tmp/cdrom/ports/games/oneko. Hay algunos ports para los que no podemos dar el código fuente original en el CDROM debido a limitaciones de licencia. Es estos casos, tendrás que mirar en la sección Compilando los ports usando una conexión a Internet. Compilando los Ports desde Internet Si no tienes CDROM o quieres estar seguro de instalar la última versión del port que te interesa, necesitarás bajarte el esqueleto de ese port. Primero, si estás usando una versión release de FreeBSD, asegúrate de tener instalado el kit de actualización apropiado para tu release. Para conocer el kit apropiado, mira en la página web de ports. Estos packages incluyen ficheros que han sido actualizados desde la release y que serán necesarios para compilar los nuevos ports. La clave para los esqueletos es que el servidor FTP de FreeBSD puede crear tarballs al momento. Aquí tienes cómo trabaja, usando como ejemplo el programa gnats en el directorio de bases de datos (el texto entre corchetes son comentarios. No los teclees si intentas ejecutar el ejemplo): &prompt.root; cd /usr/ports &prompt.root; mkdir databases &prompt.root; cd databases &prompt.root; ftp ftp.freebsd.org [log in as `ftp' and give your email address when asked for a password. Remember to use binary (also known as image) mode!] > cd /pub/FreeBSD/ports/ports/databases > get gnats.tar [tars up the gnats skeleton for us] > quit &prompt.root; tar xf gnats.tar [extract the gnats skeleton] &prompt.root; cd gnats &prompt.root; make install [build and install gnats] ¿Qué ha ocurrido aquí?. Hemos conectado con el servidor FTP de la manera habitual y entrado en el subdirectorio databases. Al enviar el comando get gnats.tar, el servidor FTP ha empaquetado en formato tarred el directorio gnats. A continuación hemos extraido el esqueleto de gnats y entrado en el directorio para compilar el port. Como hemos explicado anteriormente, el programa make ha detectado que el código fuente no estaba disponible localmente y lo ha bajado de Internet antes de extraerlo, aplicar los parches necesarios, compilarlo e instalarlo. Intentemos ahora algo más ambicioso. En lugar de obtener el esqueleto de un simple port, obtengamos todos los de un directorio, por ejemplo los esqueletos de todas las bases de datos de la colección de ports. El proceso es muy parecido: &prompt.root; cd /usr/ports &prompt.root; ftp ftp.freebsd.org [log in as `ftp' and give your email address when asked for a password. Remember to use binary (also known as image) mode!] > cd /pub/FreeBSD/ports/ports > get databases.tar [tars up the databases directory for us] > quit &prompt.root; tar xf databases.tar [extract all the database skeletons] &prompt.root; cd databases &prompt.root; make install [build and install all the database ports] Con media docena de sencillos comandos, tenenemos instalada toda una serie de programas de bases de datos en nuestra máquina FreeBSD. Todo lo que hemos hecho diferente de la instalación de un sólo port ha sido bajarnos todo un directorio y compilarlo todo de una sola vez. Impresionante, ¿no?. Si tienes pensado instalar muchos ports, es buena idea bajarse la colección de ports completa. Esqueletos Un grupo de hackers compulsivos que ha olvidado comer en un intento de llegar a un punto prefijado?. No, un esqueleto aquí es la expresión mínima que incluye todo lo necesario para que los ports realicen su mágico trabajo. <filename>Makefile</filename> El componente más importante del esqueleto es el Makefile. Este contiene diferentes declaraciones que especifican cómo debe ser compilado e instalado un port. Aquí está el Makefile para el port ElectricFence: # New ports collection makefile for: Electric Fence # Version required: 2.0.5 # Date created: 13 November 1997 # Whom: jraynard # # $Id$ # DISTNAME= ElectricFence-2.0.5 CATEGORIES= devel MASTER_SITES= ${MASTER_SITE_SUNSITE} MASTER_SITE_SUBDIR= devel/lang/c MAINTAINER= jraynard@freebsd.org MAN3= libefence.3 do-install: ${INSTALL_DATA} ${WRKSRC}/libefence.a ${PREFIX}/lib ${INSTALL_MAN} ${WRKSRC}/libefence.3 ${PREFIX}/man/man3 .include <bsd.port.mk> Las líneas que empiezan con el símbolo "#" son comentarios para facilitar las cosas a los lectores humanos (como en la mayoría de los scripts en Unix). DISTNAME especifica el nombre del tarball, pero sin la extensión. CATEGORIES indica que tipo de programa es. En este caso, una utilidad para desarrolladores. Mira en la sección categorías de este handbook para ver una lista completa. MASTER_SITES es la URL(s) del servidor FTP principal, usado para obtener el tarball si no está disponible en el sistema local. Este servidor se considera fiable, y normalmente es desde el que se distribuye de manera oficial el programa. MAINTAINER es la dirección de email de la persona responsable de actualizar el esqueleto, si, por ejemplo, aparece una nueva versión del programa. Pasando por alto las siguientes líneas, la línea .include <bsd.port.mk> indica que las otras declaraciones o comandos necesarios para compilar el port están en un fichero estándar llamado bsd.port.mk. Como éstas son las mismas para todos los ports, no hay necesidad de duplicarlos en todos los ports, así que se mantienen en un solo fichero. Este no es el lugar para entrar en detalle sobre el funcionamiento del Makefile; es suficiente con decir que la línea que comienza con MAN3 asegura que la página man de ElectricFence sea compilada después de la instalación, para ayudar a conservar tu preciado espacio en disco. El port original no contenía el objeto install, así que las tres líneas a partir de do-install aseguran que los ficheros producidos por este port sean instalados en el lugar correcto. El directorio <filename>files</filename> El fichero que contiene el checksum del port se llama md5, ya que se usa el algoritmo MD5 para comprobar el checksum de los ports. Está en el directorio llamado files. Este directorio puede contener otros ficheros necesarios para compilar el port y que no pueden situarse en ningun otro lugar. El directorio <filename>patches</filename> Este directorio contiene los patches necesarios para hacer que todo funcione correctamente bajo FreeBSD. El directorio <filename>pkg</filename> Este programa contiene tres archivos muy comunes: COMMENT — una descripción muy corta del programa. DESCR — una descripción más detallada. PLIST — una lista de todos los archivos que serán creados cuando el programa esté instalado. ¿Qué hacer cuando un port no funciona? Oh, puedes hacer una de estas cuatro (4) cosas: Solucionarlo tú mismo. Los detalles técnicos de como trabajan los ports se pueden encontrar en Portando aplicaciones. Quejarte. Sólo hacerlo por email. Enví el mail a la dirección &a.ports; y por favor, indica el nombre/versión del port, dónde obtuviste el código fuente y cual ha sido el texto de error. Olvidarlo. Este el sistema más fácil para alguno de los pocos ports que puedan clasificarse como esenciales. Obtener el package compilado desde un servidor FTP. La colección principal de packages está en el servidor principal de FreeBSD en el directorio packages, pero por favor, mira primero en tu mirror local. Estos programas suelen dar menos problemas que intentar compilar el código fuente y es, sobre todo, mucho más rápido. Usa el programa &man.pkg.add.1; para instalar un package en tu sistema. Algunas Preguntas y Respuestas P. Pensaba que esto iba a ser una discusión sobre modems R. Ah. Debes estar pensando en los puertos serie que hay en la parte trasera de tu ordenador. Aquí usamos la palabra “port” para definir el resultado de “portar” un programa de una versión de Unix a otra. (Desafortunadamente es un mal hábito de los informáticos el usar la misma palabra para referirse a cosas completamente diferentes). P. Pensaba que usabais los packages para instalar los programas extras R. Sí, esa es la manera más rápida y fácil de instalarlos. P. Entonces, ¿Porqué usar los ports? R. Por diferentes razones: Las condiciones de la licencia de algunos programas requieren que sean distribuidos como código fuente y no en formato binario. Algunas personas no confían en las distribuciones binarias. Al menos, con el código fuente puedes (en teoría) repasarlo y detectar problemas potenciales tú mismo. Si tienes algunos parches locales, necesitas el código fuente para poder añadirlos tú mismo. Posiblemente tengas opiniones diferentes a las de otros usuarios en lo que respecta a las opciones de optimización en la compilación, creación de versiones de debug, etc. A algunos usuarios les gusta tener el código fuente para poder leerlo, retocarlo, destrozarlo (dentro de los términos de la licencia, claro), y cosas así. P. ¿Qué es un patch (parche)? R. Un parche es un pequeño fichero (normalmente) que especifica como pasar de una versión de un archivo a otra. Contiene texto que especifica cosas como “borrar línea 23”, “añadir estas dos líneas después de la línea 468” o “cambia la línea 197 por esta”. También se conoce como “diff” ya que se genera por un programa llamado así. P. Qué es un tarball? R. Es un archivo terminado en .tar o .tar.gz (con variaciones como .tar.Z, o también .tgz si intentas adecuar el nombre del archivo a un sistema de archivos DOS). Básicamente, es un árbol de directorios que ha sido archivado en un solo fichero (.tar) y opcionalmente comprimido (.gz). Esta técnica se usó originalmente para Tape ARchives (archivos de cinta) y de aquí el nombre tar, pero ahora es de uso general en la distribución deil código fuente de programas a través de Internet. Puedes ver que archivos hay en ellos, o bién extraerlos tú mismo, usando el programa estándar de Unix tar, incluido en el sistema base de FreeBSD, así: &prompt.user; tar tvzf foobar.tar.gz &prompt.user; tar xzvf foobar.tar.gz &prompt.user; tar tvf foobar.tar &prompt.user; tar xvf foobar.tar P. ¿Y el checksum? R. Es un número que se genera a partir de todo el contenido del archivo que quieres chequear. Si cambia alguno de los carácteres, el checksum no será el mismo, así que una simple comparación te permitirá conocer la diferencia. P. He hecho lo que indicais para compilar los ports desde el CDROM y todo ha funcionado bién hasta que he intentado instalar el port kermit: &prompt.root; make install >> cku190.tar.gz doesn't seem to exist on this system. >> Attempting to fetch from ftp://kermit.columbia.edu/kermit/archives/. ¿Porqué no puedo encontrarlo? R. Los términos de la licencia del programa kermit no nos permiten incluir el tarball en el CDROM, así que tendrás que bajarlo a mano. La razón por la que han salido esos errores es que no estabas conectado a Internet en el momento de la instalación. Una vez lo hayas bajado de cualquiera de los servidores arriba mencionados, puedes empezar de nuevo el proceso (intenta escoger el servidor más cercano a tí para ganar tiempo y ahorrar ancho de banda de Internet). P. He hecho lo que explicais, pero cuando intento poner el archivo en /usr/ports/distfiles aparece un error que indica que no tengo permisos. R. El mecanismo de ports busca el tarball en /usr/ports/distfiles, pero no podrás copiar nada ahí por que es un link al CDROM, el cual es de sólo lectura. Puedes indicar que busque el port en cualquier otro directorio haciendo &prompt.root; make DISTDIR=/where/you/put/it install P. ¿Sólo funciona el esquema de ports si están en /usr/ports? Mi administrador de sistema dice que tengo que poner los archivos en /u/people/guests/wurzburger, pero parece que así no funciona. R. Puedes usar las variables PORTSDIR y PREFIX para indicarle al mecanismo de ports que use directorios diferentes. Por ejemplo, &prompt.root; make PORTSDIR=/u/people/guests/wurzburger/ports install compilará el port en /u/people/guests/wurzburger/ports e instalará todos los archivos bajo /usr/local. &prompt.root; make PREFIX=/u/people/guests/wurzburger/local install compilará el port en /usr/ports y lo instalará en /u/people/guests/wurzburger/local. Y por supuesto &prompt.root; make PORTSDIR=.../ports PREFIX=.../local install combinará los dos (es demasiado extenso para escribirlo en la página, pero seguro que te haces una idea). Si no quieres tener que teclear todo esto cada vez que instalas un ports, es una buena idea poner estas variables como variables de entorno. P. No tengo el CDROM de FreeBSD pero me gustaría disponer de todos los tarball en mi sistema para no tener que esperar a que se bajen de Internet cada vez que instalo un port. Hay alguna manera sencilla de hacerlo? R. Para obtener todos los tarball de la colección completa de ports haz &prompt.root; cd /usr/ports &prompt.root; make fetch Para todos los tarball de un directorio de ports, haz &prompt.root; cd /usr/ports/directory &prompt.root; make fetch y para un solo port, bueno, creo que ya lo has adivinado. P. Sé que probablemente es más rápido obtener los tarballs desde un mirror de FreeBSD cercano. ¿Hay alguna manera de obtener los ports de otros servidores diferentes a los establecidos en MASTER_SITES? R. Sí. Si sabes, por ejemplo que ftp.FreeBSD.ORG te es más cercano que los servidores listados en MASTER_SITES, haz como en el siguiente ejemplo. &prompt.root; cd /usr/ports/directory &prompt.root; make MASTER_SITE_OVERRIDE=ftp://ftp.FreeBSD.ORG/pub/FreeBSD/ports/distfiles/ fetch P. Quiero saber que ficheros va a necesitar el programa make antes de que intente bajarlos. R. make fetch-list mostrará una lista de los ficheros necesarios para el port. P. ¿Hay alguna manera de parar la compilación del port?. Quiero hacer algunos retoques en el código fuente antes de instalarlo, pero es un poco pesado tener que estar atento y pulsar control-C cada vez. R. Ejecutando make extract, el port parará después de haber obtenido y extraido el código fuente. P. Estoy intentando crear mi propio port y quiero poder parar la compilación hasta poder asegurarme de que mis parches funcionan correctamente. ¿Hay alguna comando como make extract, pero para parches? R. Sí, make patch es lo que quieres. Probablemente también encontrarás muy útil la opción PATCH_DEBUG. Y ya de paso, gracias por el esfuerzo!. P. He oido que algunas opciones de compilación pueden causar errores. ¿Es cierto?. ¿Cómo puedo asegurarme de que compilo los ports con las opciones correctas?. R. Sí, con la versión 2.6.3 de gcc (la versión incluida en FreeBSD 2.1.0 y 2.1.5), la opción puede crear problemas a no ser que uses también la opción . (Muchos de los ports no usan ). Deberís poder especificar las opciones de compilación con algo como &prompt.root; make CFLAGS='-O2 -fno-strength-reduce'install o editando el fichero /etc/make.conf, pero desafortunadamente no todos los ports respetan esto. La forma más segura es hacer make configure, entrar en el directorio de los fuentes e inspeccionar a mano los Makefiles, pero puede ser muy tedioso si los fuentes tienen muchos subdirectorios, cada uno con su propio Makefile. P. Hay tantos ports que resulta complicado encontrar el que quiero. ¿Hay alguna lista de los ports disponibles? R. Mira el archivo INDEX en /usr/ports. También puedes hacer búsquedas de palabras en la colección de ports. Por ejemplo puedes encontrar ports referentes al lenguaje de programación LISP usando: &prompt.user; cd /usr/ports &prompt.user; make search key=lisp P. Iba a instalar el port foo pero de pronto el sistema paró la compilación y comenzó a compilar el port bar. ¿Qué está pasando? R. El port foo necesita algo que ofrece el port bar, por ejemplo, si foo usa gráficos, bar puede tener librerías con rutinas de procesamiento gráfico útiles. O puede ser que bar sea una herramienta necesaria para compilar el port foo. P. Instalé el programa grizzle desde los ports, y, francamente, me parece una pérdida de espacio en disco, Quiero borrarlo pero no sé dónde están todos los ficheros. ¿alguna idea? R. No hay problema, sólo haz &prompt.root; pkg_delete grizzle-6.5 P. Espera un momento; necesitas saber el número de versión para usar ese comando. No creerás que voy a ser capaz de recordarlo, ¿no? R. No, desde luego. Puedes encontrar el número de versión haciendo &prompt.root; pkg_info -a | grep grizzle Information for grizzle-6.5: grizzle-6.5 - the combined piano tutorial, LOGO interpreter and shoot 'em up arcade game. P. Hablando de espacio en disco, el directorio de ports parece que cada vez ocupa más espacio. ¿Es recomendable borrar cosas? R. Sí, si ya tienes instalado el programa y crees que no vas a necesitarlo de nuevo. La mejor manera de hacerlo es &prompt.root; cd /usr/ports &prompt.root; make clean lo que entrará en todos los subdirectorios de ports y borrará todo excepto el esqueleto de cada port. P. He hecho lo que comentais y todavía tengo todos esos tarballs o como le llameis en el directorio distfiles. ¿Puedo borrar esos archivos? R. Sí, si estás seguro de haber terminado con ellos. P. Me gusta tener muchos programas para poder jugar con ellos. ¿Hay alguna manera de instalar todos los ports de una vez? R. Sólo haz &prompt.root; cd /usr/ports &prompt.root; make install P. Bién, lo he intentado, pero pensando que tardaría mucho me fuí a dormir y cuando he vuelto esta mañna he visto que sólo había instalado tres ports y medio. ¿Ha ido algo mal? R. No, el problema es que algunos ports necesitan hacer preguntas que no podemos responder por tí y necesitan tener a alguien "a mano" para poder responderlas. P. Realmente, no quiero perder todo un día delante del monitor. ¿Alguna idea mejor? R. Bueno, haz esto antes de irte a dormir &prompt.root cd /usr/ports &prompt.root; make -DBATCH install Esto instalará todos los ports que no requieran participación por parte del usuario. Entonces, cuando vuelvas haz &prompt.root; cd /usr/ports &prompt.root; make -DIS_INTERACTIVE install para terminar el trabajo. P. En el trabajo, estamos usando el programa frobble, que está en la colección de ports, pero lo hemos alterado un poco para cubrir nuestras necesidades. ¿Hay alguna manera sencilla de hacer nuestros propios packages de manera que podamos distribuirlos más fácilmente en nuestros servidores? R. No hay problema, asumiendo que sabes como hacer los parches para tus cambios: &prompt.root; cd /usr/ports/somewhere/frobble &prompt.root; make extract &prompt.root; cd work/frobble-2.8 [Apply your patches] &prompt.root; cd ../.. &prompt.root; make package P. Este sistema de ports es realmente fantástici. Estoy desesperado por saber como lo habeis hecho. ¿Cuál es el - secreto? R. No hay nada secreto, lo tienes todo en los ficheros bsd.ports.mk y bsd.ports.subdir.mk en tu directorio de makefiles. Los lectores con aversión a intrincados shell-scripts están avisados de no seguir este link...) Haciendo tú mismo un port Contribuido por &a.jkh;, &a.gpalmer;, &a.asami; &a.obrien; y &a.hoek;. 28 de Agosto de 1996. Así que, ¿ahora estás interesado en hacer un port?. Bién! Lo que viene a continuación son algunas guís para crear un nuevo port para FreeBSD. La mayoría del trabajo es hecha por el fichero /usr/ports/Mk/bsd.port.mk que incluyen todos los Makefile de los ports. Por favor, mira en este fichero para más información sobre la manera de trabajar de la colección de ports. Aunque no uses los Makefiles de manera habitualm, está bién comentado, y podrás conocer una gran cantidad de cosas a través de él. Sólo una pequeña parte de las variables sobreescribibles (VAR) se mencionan en este documento. Muchas (si no todas) están documentadas al inicio del fichero bsd.port.mk. Este fichero usa una tabulación no estándar. Emacs y Vim deberín reconocer la configuración al cargar el fichero. vi or ex se pueden configurar para que usen los valores correctos tecleando :set tabstop=4 una vez que el fichero ha sido cargado. Haciendo Ports rápidamente Esta sección te explica cómo hacer un port rápidamente. En muchos casos no es suficiente, pero ya lo iremos viendo. Primero, obtén el tarball original y ponlo en DISTDIR, que por defecto apunta a /usr/ports/distfiles. Los siguientes comentarios asumen que el software compila sin problema alguno en FreeBSD, y no se requiere absolutamente ningún cambio para que el port funcione en tu sistema FreeBSD. Si has necesitado modificar alguna cosa, tendrás que referirte también por la siguiente sección. Escribiendo el <filename>Makefile</filename> El Makefile debería ser algo como esto: # New ports collection makefile for: oneko # Version required: 1.1b # Date created: 5 December 1994 # Whom: asami # # $Id$ # DISTNAME= oneko-1.1b CATEGORIES= games MASTER_SITES= ftp://ftp.cs.columbia.edu/archives/X11R5/contrib/ MAINTAINER= asami@FreeBSD.ORG MAN1= oneko.1 MANCOMPRESSED= yes USE_IMAKE= yes .include <bsd.port.mk> Prueba de entenderlo tú mismo. No te preocupes por los contenidos de la línea $Id$, ya que serán completadas automaticamente por el CVS cuando el port sea importado a la colección de ports principal. Puedes encontrar información más detallada en la sección Makefile de ejemplo. Escribiendo los ficheros de descripción Hay tres ficheros de descripción que son requeridos por cualquier port. Los ficheros son COMMENT, DESCR y PLIST. Estos ficheros deben estar en el subdirectorio pkg. <filename>COMMENT</filename> Descripción corta del port. Por favor no incluir el nombre del package (o número de versión del software) en el comentario. Aquí tienes un ejemplo: A cat chasing a mouse all over the screen. <filename>DESCR</filename> Esta es una descripción más detallada del port. Uno o varios párrafos explicando claramente que hace el port es suficiente. Este no es un manual o una descripción en profundidad de cómo usar o compilar el port! Por favorm, ten cuidado si lo estás copiando del README o del man. Si el software portado tiene una página web oficial, deberías listarlo aquí. Te recomendamos que pongas tu nombre o firma al final de este fichero de la manerae siguiente: This is a port of oneko, in which a cat chases a poor mouse all over the screen. : (etc.) http://www.oneko.org/ - Satoshi asami@cs.berkeley.edu <filename>PLIST</filename> Este fichero lista todos los ficheros instalados por el port. También se llama “packing list” por que el package es generado con los ficheros listados aquí. Los paths son relativos al prefijo de instalación (normalmente /usr/local o /usr/X11R6). Si estás usando las variables MANn (como deberís hacer), no listes ninguna página man aquí. Aquí tienes un pequeño ejemplo: bin/oneko lib/X11/app-defaults/Oneko lib/X11/oneko/cat1.xpm lib/X11/oneko/cat2.xpm lib/X11/oneko/mouse.xpm @dirrm lib/X11/oneko Mira en el man de &man.pkg.create.1; para más detalles sobre la "lista de empaquetado". Deberís listar todos los ficheros, pero no los nombres de los directorios. De la misma manera, si el port crea directorios por sí mismo durante la instalación, asegúrate de añadir las líneas @dirrm cuando sea necesario para eliminarlos cuando el port sea desinstalado. Es recomendable que mantengas todos los nobres de fichero en este archivo ordenados alfabéticamente. Hará que la verificación de cambios cuando actualices el port sea mucho más sencilla. Creando el fichero de checksum Solo teclea make checksum. Las reglas del programa make para los ports generarán automáticamente el fichero files/md5. Testeando los ports Debes asegurarte de que las reglas de los ports hagan exactamente lo que quieres que hagan, incluyendo el empaquetado del port. Estos son los puntos importantes que necesitas verificar: PLIST no contiene nada que no sea instalado por tu port PLIST contiene absolutamente todos los ficheros instalados por tu port Tu port puede ser instalado múltiples veces usando el parámetro reinstall Tu port se elimina a sí mismo al usar el parámetro deinstall Orden de test recomendado make install make package make deinstall pkg_add `make package-name` make deinstall make reinstall make package Asegúrate de que no existe ningún warning en los comandos package y deinstall. Después del paso 3, mira si todos los nuevos directorios han sido eliminados correctamente. también, intenta usar el software después del paso 4, para asegurarte de que funciona correctamente cuando es instalado desde un package. Probando tu port con <command>portlint</command> Por favor, usa el comando portlint para ver si tu port cumple nuestras normas. El programa portlint forma parte de la colección de ports. En particular, debes probar que el Makefile es correcto y que el package es nombrado apropiadamente. Enviando un port Primero, asegúrate de haber leido la sección Do's and Dont's. Ahora que ya tienes tu port, solo queda incluirlo en la colección de ports principal de FreeBSD y que todo el mundo lo tenga a su alcance. No necesitamos tu directorio work o el archivo de package pkgname.tgz, así que bórralos ahora. A continuación, simplemente incluye la salida de shar `find port_dir` en un "bug report" y envialo con el programa &man.send-pr.1; (mira en Bug Reports y comentarios generales para más información sobre &man.send-pr.1;. Si el port descomprimido es mayor de 20Kb deberías comprimirlo en un fichero tar y usar el comando &man.uuencode.1; antes de incluirlo en el bug report. Clasifica el bug report en la categoría ports y clase change-request. No marques el port como confidencial!) Una vez más, no incluyas el código fuente original, el directorio work, o el package creado con make package. En el pasado, te recomendabamos enviar el nuevo port a nuestro servidor ftp (ftp.freebsd.org). Esto ya no es recomendando ya que el permiso de lectura se ha desactivado en el directorio incoming por la cantidad de software pirata que se enviaba. Miraremos tu port, nos pondremos en contacto contigo si es necesario y lo añadiremos en la colección principal. Tu nombre aparecerá en la lista “Additional FreeBSD contributors” en el Handbook de FreeBSD y otros ficheros. ¿No es genial?!? :) Ports paso a paso Bién, así que no ha sido tan simple, y el port ha necesitado algunas modificaciones para funcionar. En esta sección, explicaremos, paso a paso, como modificarlo para que pueda funcionar en el entorno de los ports. Cócomo funcionan las cosas Primero, esta es la secuencia de eventos que ocurren cuando un usuario teclea make en el directorio de ports. Si tienes otra ventana con el fichero bsd.port.mk te resultará más sencillo entender todo el proceso. Pero no te preocupes si realmente no entiendes todo lo que hace el fichero bsd.port.mk... no hay mucha gente que realmente lo entienda... :> El objeto fetch es ejecutado. El objeto fetch es el responsable de asegurar que el tarball necesario existe localmente en el directorio DISTDIR. Si fetch no puede encontrar los ficheros requeridos en DISTDIR localizará el URL de MASTER_SITES, la cual existe en el Makefile, al igual que en nuestro servidor principal ftp ftp://ftp.freebsd.org/pub/FreeBSD/ports/distfiles/, que usamos como servidor de backup. A continuación intentará obtener el archivo de la distribución con FETCH, asumiendo que el servidor de origen tiene conexión directa a Internet. Si este paso termina correctamente, grabará el archivo en DISTDIR para su uso futuro. El objeto extract es ejecutado. Busca el archivo de distribución del port (normalmente un tarball comprimido con gzip) en DISTDIR y lo descomprime en un sibdirectorio temporal especificado por la variable WRKDIR (normalmente work). Se ejecuta el objeto patch. Primero se aplican todos los parches definidos en PATCHFILES. A continuación, si no se han encontrado parches en PATCHDIR (que por defecto está definido como el subdirectorio patches), son aplicados en orden alfabético. Se ejecuta el objeto configure. Este puede hacer cualquiera de las siguientes funciones. Si existe, se ejecuta scripts/configure. Si USE_IMAKE está definido, se ejecuta XMKMF (por defecto: xmkmf -a). Se ejecuta el objeto build. Este es responsable de descender por los directorios de trabajo privados del port (WRKSRC) y compilarlos. Si se ha definido USE_GMAKE se usa el comando make, en caso contrario, se usará el comando de sistema make. Las anteriores, son las acciones por defecto. Además, puedes definir los objetos pre-algo o post-something, o poner scripts con esos nombres. En el subdirectorio scripts, y serán ejecutados antes o después de las acciones por defecto. Por ejemplo, si tienes definido un objeto post-extract en tu Makefile, y un fichero pre-build en el subdirectorio scripts, el objeto post-extract será llamado después de las acciones de extracción regulares, y el script pre-build será ejecutado antes que las reglas por defecto de compilación. Es recomendable que uses objetos de Makefile en caso de que las acciones a realizar sean suficientemente simples, ya que así resultará mucho más sencillo saber que tipo de acciones no regulares requiere el port. Las acciones por defecto son ejecutadas por los objetos do-something del fichero bsd.port.mk. Por ejemplo, los mandatos para extraer un port están en el objeto do-extract. Si necesitas algo no incluido en el objeto por defecto, puedes solucionarlo redefiniendo el objeto do-something en tu Makefile. Los objetos “principales” (por ejemplo, extract, configure, etc.) no hacen nada más que asegurar que se han completado todos los procesos y llamar a los objetos o scripts reales, y no se espera que sean modificados. Si quieres modificar la extracción, cambia el objeto do-extract, pero nunca modifiques el objeto extract! Ahora que entiendes lo que pasa cuando un usuario teclea make, déjanos explicarte los pasos recomendados para crear el port perfecto. Obteniendo los fuentes originales Obtén los fuentes originales (normalmente) en un archivo comprimido (foo.tar.gz o foo.tar.Z) y copialo en el directorio DISTDIR. Usa siempre dónde y cuando puedas los fuentes procedentes del servidor principal de la distribución. Si no puedes encontrar un servidor ftp/http con una buena conexión a Internet, o sólo encuentras servidores que tienen los fuentes en irritantes formatos no estándar, puedes poner una copia funcional del archivo en un servidor ftp o http bajo tu control (tu página personal, por ejemplo). Asegúrate de usar el valor correcto en la variable MASTER_SITES para que refleje tu elección. Si no puedes encontrar ningún lugar en el que poner el fichero de distribución (si eres committer de FreeBSD, puedes ponerlo en el directorio public_html/ del servidor freefall), nosotros podemos albergarlo en ftp://ftp.freebsd.org/pub/FreeBSD/ports/distfiles/LOCAL_PORTS/ como último recurso. Por favor, usa la variable MASTER_SITE_LOCAL para referirte a este servidor y subdirectorio. Envía un mail a &a.ports; si no estás seguro de qué hacer. Si tu archivo de distribución cambia continuamente sin una buena razón, considera poner el archivo en tu página personal y listarlo como el primer MASTER_SITES. Esto evitará que los usuarios obtengan errores del tipo checksum mismatch, y también reducirá la carga de trabajo de las personas que hacen el mantenimiento de nuestro servidor FTP. De la misma manera, si existe un solo servidor como distribuidor principal del programa, es recomendable que albergues una copia de la distribución en tu servidor y lo listes como segundo MASTER_SITES. Si tu port requiere algunos parches adicionales que están disponibles en Internet, bájalos y ponlos en DISTDIR. No te preocupes si provienen de un lugar diferente del que obtuviste el tarball principal, tenemos una manera de solucionar este problema (consulta la descripción de PATCHFILES). Modificando el port Descomprime una copia del tarball en un directorio privado y haz todos los cambios necesarios para que el port compile en la versión actual de FreeBSD. Mantén una lista completa de todas las modificaciones que realizas para poder automatizar el proceso. Todo, incluyendo borrar, añadir o modificar ficheros debe poder hacerse de manera automática usando un script o parche. Si tu port requiere una importante interacción o personalización para compilar o instalar, puedes mirar la clásica aplicación Configure de Larry Wall y hacer algo así tu mismo. El objetivo de la nueva colección de ports es hacer que cada port sea tan “plug-and-play” como sea posible para el usuario final, usando el mínimo espacio en disco posible. Aunque no se haya mencionado explícitamente, los parches, scripts y otros archivos que hayas creado o contribuido a la colección de ports de FreeBSD están cubiertos por las condiciones estándar del copyright BSD. Parcheando En la preparación del port, los archivos que han sido añdidos o modificados pueden recorrerse con un diff recursivo. Cada serie de parches que quieras aplicar deben estar integrados en un archivo llamado patch-xx donde xx marca la secuencia en que los parches serán aplicados — éstos se aplican en órden alfabético, así primero será aa, segundo ab ,etc. Estos archivos deben estar en PATCHDIR, desde donde serán automáticamente aplicados. Todos los parches deben ser relativos a WRKSRC (generalmente es el directorio en el que se descomprime el port, siendo éste el lugar donde se compila). Para hacer que la solución de problemas y actualizaciones sea más sencilla, deberís evitar tener más de un parche aplicable a un mismo archivo (por ejemplo, patch-aa y patch-ab modificando ambos al archivo WRKSRC/foobar.c). Configurando Incluye cualquier proceso de personalización adicional en el script configure y guardalo en el subdirectorio scripts. Como se ha mencionado anteriormente, también puedes hacer esto como un objeto del Makefile y/o un script con el nombre pre-configure o post-configure. Gestionando las entradas de usuario Si tu port requiere entradas por parte del usuario para la compilación, configuración o instalación, activa la variable IS_INTERACTIVE en tu Makefile. Esto permitirá no compilar tu port si el usuario usa la variable BATCH en su entorno (y si el usuario activa la variable INTERACTIVE, entonces sólo serán compilados los ports que requieren interacción por parte del usuario). También es recomendable desactivar el script interactivo si un número razonable de respuestas por defecto son aplicables al port (consultar la variable PACKAGE_BUILDING). Esto nos permitirá compilar el package para los CD-ROMs y ftp. Configurando el Makefile Configurar el Makefile es bastante sencillo, y de nuevo, te sugerimos que consultes los ejemplos existentes antes de empezar. También hay un Makefile de ejemplo en este handbook, así que, consultalo y, por favor, sigue el órden de las variables y secciones del ejemplo para que tu port sea más fácil de leer para otras personas. Ahora, considera los siguientes problemas a medida que haces el diseño de tu nuevo Makefile: Los fuentes originales Reside en DISTDIR como un tarball estándar en formato gzip? Si es así puedes pasar al siguiente paso. En caso contrario, deberías considerar la posibilidad de sobreescribir alguna de las variables EXTRACT_CMD, EXTRACT_BEFORE_ARGS, EXTRACT_AFTER_ARGS, EXTRACT_SUFX, o DISTFILES, dependiendo del formato del archivo de distribución del port. (El caso más común es EXTRACT_SUFX=.tar.Z, cuando el tarball está comprimido con compress y no con gzip.) En el peor de los casos, puedes crearte tu propio objeto do-extract para sobreescribir el objeto por defecto. <makevar>DISTNAME</makevar> El valor de DISTNAME debe ser el nombre base del port. Las reglas por defecto esperan que la lista de archivos de la distribución (DISTFILES) se llame DISTNAMEEXTRACT_SUFX, el cual, si es un tarball normal, seráa algo como foozolix-1.0.tar.gz para usar el valor DISTNAME=foozolix-1.0. Las reglas por defecto también esperan extraer el tarball en un subdirectorio llamado work/DISTNAME, por ejemplo work/foozolix-1.0/. Todos estos valores pueden sobreescribirse; simplemente muestran los valores más habituales. Para un port que requiera múltiples archivos de distribución, simplemente usa explícitamente DISTFILES. Si solo una parte de los DISTFILES son archivos extraibles, entonces usa EXTRACT_ONLY para referenciarlos, lo que sobreescribirá la lista DISTFILES cuando realice la extracción, y el resto de archivos se dejarán en DISTDIR tal y como están para su uso posterior. <makevar>PKGNAME</makevar> Si DISTNAME no sigue las normas de nombre para un package, deberís asignar a la variable PKGNAME un valor más correcto. <makevar>CATEGORIES</makevar> Cuando se crea un package, se incluye en el directorio /usr/ports/packages/All creandose links desde uno o más subdirectorios de /usr/ports/packages. Los nombres de estos subdirectorios están especificados por la variable CATEGORIES. Se utiliza para facilitar al usuario la orientación dentro de la colección de ports y packages. Por favor, consulta las categorías existentes y elige las que sean aplicables a tu port. Esta lista también determina en que lugar del árbol de ports se importa el port. Si especificas más de una categoría, se asume que los archivos del port estarán en el subdirectorio con el nombre en la primera categoría. Consulta la sección categorías para saber como escoger la catergoría adecuada. Si tu port pertenece realmente a una categorín inexistente, puedes crear una nueva. En este caso, por favor, envía un mail a &a.ports; para proponer una nueva categoría. No hay chequeo de error para los nombres de categorías. make package creará un nuevo directorio si tecleas mal el nombre de la categorí, así que se cuidadoso! <makevar>MASTER_SITES</makevar> Guarda la parte del directorio del URL -ftp/hhtp que apunta al tarball original en MASTER_SITES. No olvidar la barra final (/)! Las macros make intentaran usar esta especificación para obtener el archivo de distribución con FETCH si no lo pueden encontrar en el sistema. Se recomienda poner diferentes servidores en la lista, preferiblemente de continentes diferentes. Esto protegerá de posibles problemas de red en grandes áreas, y se está pensando en la posibilidad de añadir soporte para determinar automáticamente el servidor principal más cercano para obtener el archivo desde él. Si el tarball original forma parte de uno de estos servidores populares: X-contrib, GNU, Perl CPAN, TeX CTAN o Linux Sunsite, se debe hacer referencia a estos servidores usando MASTER_SITE_XCONTRIB, MASTER_SITE_GNU, MASTER_SITE_PERL_CPAN, MASTER_SITE_TEX_CTAN, y MASTER_SITE_SUNSITE. Simplemente poner MASTER_SITE_SUBDIR al path interno del servidor. Aquí hay un ejemplo: MASTER_SITES= ${MASTER_SITE_XCONTRIB} MASTER_SITE_SUBDIR= applications El usuario también puede usar las variables MASTER_SITE_* en el archivo /etc/make.conf para sobreescribir nuestras selecciones, y usar en su lugar el mirror que prefiera de estos servidores. <makevar>PATCHFILES</makevar> Si el port requiere parches adicionales que están disponibles por ftp o http, poner PATCHFILES a los nombres de archivos y PATCH_SITES a la URL del directorio que los contiene (el formato es el mismo que en MASTER_SITES). Si el parche no es relativo a la raíz del árbol (WKRSRC) porque contiene alguna información extra sobre paths, usar la variable PATCH_DIST_STRIP. Por ejemplo, si todos los path del parche contienen foozolix-1.0/ delante del nombre de archivo, usar PATCH_DIST_STRIP=-p1. No preocuparse si los parches están comprimidos, serán descomprimidos automáticamente si el nombre de archivo termina en .gz o .Z. Si el parche se distribuye con otros archivos, como documentación, en un tarball gzip, no se puede usar PATCHFILES. Si este es el caso, añadir el nombre y situación del tarball a DISTFILES y MASTER_SITES. A continuación, desde el objeto pre-patch, aplicar el parche ejecutando mandato patch desde él, el copiando al archivo del parche en el directorio PATCHDIR llamandolo patch-xx. Tener en cuenta que el tarball será extraido del fuente regular, por lo que no es necesario extraerlo explícitamente si es un tarball comprimido con gzip o compress. Si se hace lo último, tener cuidado de no sobreescribir algo ya existente en ese directorio. No olvidarse de añadir un mandato para borrar el parche copiado en el objeto pre-clean <makevar>MAINTAINER</makevar> Poner aquí la dirección de mail. Por favor. :) Para una descripción detallada de la responsabilidad de los "maintainers", consultar la sección MAINTAINER en Makefiles. Dependencias Muchos ports dependen de otros. Hay cinco variables que se pueden usar para asegurar que existen todos los requerimientos necesarios en la máquina del usuario. También hay algunas variables de dependencia pre-soportadas para casos comunes, mas algunos controles de dependencia. <makevar>LIB_DEPENDS</makevar> Esta variable especifica las librerías compartidas de las que depende el port. Es una lista de registros de lib:dir:target donde lib es el nombre de la librerí compartida, y dir es el directorio en el cual encontrarla en caso de no estar disponible y target es el objeto a llamar en ese directorio. Por ejemplo, LIB_DEPENDS=jpeg.9:${PORTSDIR}/graphics/jpeg:install comprobará la existencia de la librería jpeg versión 9, descendiendo al subdirectorio graphics/jpeg de la colección de ports para compilarlo e instalarlo en caso de que no sea encontrado en el sistema. El objeto target puede omitirse si es igual a DEPENDS_TARGET (el cual, por defecto, tiene el valor install). La parte lib es un argumento dado a ldconfig -r | grep -wF. Es posible que no existan expresiones regulares en esta variable. La dependencia se comprueba dos veces, una durante la ejecución de extract y otra durante la ejecución de install. También, se incluye el nombre de la dependencia en el package, de manera que pkg_add la instale automáticamente si no está en el sistema del usuario. <makevar>RUN_DEPENDS</makevar> Esta variable especifica ejecutables o archivos de los que depende la compilació y/o ejecución de este port. Es una lista de tuples path:dir:target donde path es el nombre del ejecutable o archivo, dir es el directorio en el que encontrarlo en caso de no estar disponible y target es el objeto a llamar en ese directorio. Si path empieza con una barra (/), se trata como un archivo comprobando su existencia con test -e; en caso contrario, se asume que es un ejecutable, y se usa which -s para determinar si el programa existe en el path del usuario. Por ejemplo, RUN_DEPENDS= ${PREFIX}/etc/innd:${PORTSDIR}/news/inn \ wish8.0:${PORTSDIR}/x11-toolkits/tk80 comprobará si existe el directorio o archivo /usr/local/etc/innd, compilando e instalandolo desde el directorio news/inn del árbol de ports en caso de no existir. También se comprueba la existencia del ejecutable wish8.0 en el path, descendiendo al subdirectorio x11-toolkits/tk80 de los ports para compilarlo e instalarlo si no existe. En este caso, innd es un ejecutable; si un ejecutable está situado en un lugar diferente al esperado (fuera del path), es necesario incluir el path completo. La dependencia se comprueba desde el objeto install. El nombre de la dependencia también es incluido en el package para que pkg_add lo instale automáticamente si no existe en el sistema del usuario. La parte target puede omitirse si es el mismo DEPENDS_TARGET. <makevar>BUILD_DEPENDS</makevar> Esta variable especifica los ejecutables o archivos que este port necesita para compilar. Igual que RUN_DEPENDS, es una lista de tuples path:dir:target. Por ejemplo, BUILD_DEPENDS= unzip:${PORTSDIR}/archivers/unzip comprobará la existencia de un ejecutable llamado unzip, descendiendo al subdirectorio archivers/unzip en caso de no existir, para compilarlo e instalarlo. Compilación en este caso, se refiere a todo el proceso; desde la extracción hasta la compilación final. La dependencia se comprueba en el objeto extract. La parte target puede omitirse si la misma que DEPENDS_TARGET <makevar>FETCH_DEPENDS</makevar> Esta variable especifica ejecutables o archivos que se requieren para obtener este port. Como los dos anteriores, es una lista de tuples path:dir:target. Por ejemplo, FETCH_DEPENDS= ncftp2:${PORTSDIR}/net/ncftp2 comprobará la existencia de un ejecutable llamado ncftp2, descendiendo al subdirectorio net/ncftp2 de los ports para compilarlo e instalarlo en caso de no existir. La dependencia es comprobada en el objeto fetch. La parte target puede omitirse si es la misma que DEPENDS_TARGET. <makevar>DEPENDS</makevar> Si hay una dependencia que no se puede incluir en las cuatro categorías anteriores, o el port necesita tener extraidos los fuentes de otro port para poder ser instalado, usar esta variable. Esta es una lista compuesta de dir:target, ya que no no hay nada que comprobar, al contrario que las cuatro anteriores. La parte target puede omitirse si es la misma que DEPENDS_TARGET. Variables de dependencia comunes Definir USE_XLIB=yes si el port requiere la instalación del sistema X Window (implícito en USE_IMAKE). Definir USE_GMAKE=yes si el port requiere el make de GNU en lugar del make de BSD. Definir USE_AUTOCONF=yes si el port requiere la ejecución del autoconf de GNU. Definir USE_QT=yes si el port usa el último kit qt. Usar USE_PERL5=yes si el port requiere la versión 5 del lenguaje perl. (Este último es especialmente importante ya que unas versiones de FreeBSD contienen perl5 como parte del sistema y otras no.) Notas sobre dependencias Cómo se ha mencionado anteriormente, el objeto por defecto a llamar cuando se require una dependencia es DEPENDS_TARGET. Por defecto es install. Esta es una variable de usuario; nunca se define en los Makefile de los ports. Si un port necesita gestionar las dependencias de manera especial, usar la parte :target de las variables *_DEPENDS en lugar de redefinir DEPENDS_TARGET. Cuando se ejecuta make clean, sus dependencias también son "limpiadas". Si se quiere evitar esto, hay que definir la variable NOCLEANDEPENDS en el entorno. Para depender incondicionalmente de un port, es imprescindible usar la cadena de texto nonexistent como primer campo de BUILD_DEPENDS o RUN_DEPENDS. Usar esto sólo cuando es necesario disponer del código fuente de otro port. Se puede ahorrar tiempo de compilación especificando el objeto. Por ejemplo: BUILD_DEPENDS= /nonexistent:${PORTSDIR}/graphics/jpeg:extract siempre descenderá al port JPEG y lo extraerá. No usar DEPENDS a no ser que no exista otra manera de obtener los resultados deseados. Hará que el otro port siempre sea compilado (e instalado, por defecto), y la dependencia sea añadia al package. Si esto es lo que realmente se necesita, es recomendable usar BUILD_DEPENDS y RUN_DEPENDS. Mecanismos de creación Si el package usa GNU make, definir USE_GMAKE=yes. Si el package usa configure, definir HAS_CONFIGURE=yes. Si el package usa GNU configure, definir GNU_CONFIGURE=yes (esto implica HAS_CONFIGURE). Si se quieren pasar argumentos extra a configure (el argumento por defecto es --prefix=${PREFIX} para GNU configure y vacío para no GNU configure), definir los argumentos extra en CONFIGURE_ARGS. Si el package usa GNU autoconf, definir USE_AUTOCONF=yes. Esto implica GNU_CONFIGURE, y causará la ejecución de autoconf antes que configure. Si el package es una aplicación X que crea archivos Makefiles desde Imakefiles usando imake, definir USE_IMAKE=yes. Esto hará que durante el proceso de configuración se ejecute el mandato xmkmf -a. Si el argumento es problemático para el port, definir XMKMF=xmkmf. Si el port usa el mandato imake pero no entiende el objeto install.man, definir NO_INSTALL_MANPAGES=yes. Si el código fuente incluido en el Makefile del port tiene algo más que el objeto all como objeto principal de creación, definir ALL_TARGET correctamente. Hacer lo mismo con install y INSTALL_TARGET. Consideraciones especiales Hay más cosas a tener en cuenta a la hora de crear un port. Esta sección explica las más comunes. <command>ldconfig</command> Si el port instala una librería compartida, añadir un objeto post-install al Makefile para que ejecute ${LDCONFIG} -m en el directorio donde se ha instalado la nueva librería (normalmente PREFIX/lib) para registrarla en el caché de librerías compartido. También, añadir un par @exec /sbin/ldconfig -m y @unexec /sbin/ldconfig -R al archivo pkg/PLIST para que el usuario que ha instalado el port pueda usar la librería compartida inmediatamente. Estas líneas deben estar inmediatamente después de la línea de la propia librería compartida, como en: lib/libtvl80.so.1 @exec /sbin/ldconfig -m %D/lib @unexec /sbin/ldconfig -R Nunca, nunca, nunca añadir una línea que ponga ldconfig sin argumentos en el Makefile o pkg/PLIST. Esto hará que el caché de librerías compartidas se resetee sólo con los contenidos de /usr/lib, probablemente, dejando el sistema inestable ("Ayuda, xinit no ha vuelto a funcionar desde que instalé este port"). Cualquiera que haga esto, será troceado en 65.536 partes con un cuchillo poco afilado, permaneciendo por toda la eterniadad en lo más profundo del infierno (y no necesariamente en este órden) Soporte ELF Desde la transición de FreeBSD a formato ELF después de la version 3.0-RELEASE, fue necesario convertir muchos ports para que generasen librerías compartidas en formato ELF. Para complicar más el trabajo, los sistemas 3.0 pueden ejecutar ELF y a.out, y se quiere mantener, etraoficialmente, tanto como sea posible, el soporte para versiones 2.2. A continuación se explica como convertir ports que sólo soportan a.out para que soporten compilaciones a.out y ELF. Una parte de esta lista sólo es aplicable durante la conversión, pero se mantendrá durante un tiempo como referencia en caso de querer actualizar algún port antiguo. Mover las librerías a.out Las librerías a.out deben moverse de /usr/local/lib y similares a un subdirectorio aout. (Si no se mueven, los ports ELF sobreescribirán las librerías a.out). El objeto move-aout-libs del archivo src/Makefile en 3.0-CURRENT (llamado desde aout-to-elf) hará este paso en nuestro lugar. Sólo moverá las librerías a.out en los directorios estándar. Formato La colección de ports compilará los packages en el mismo formato en el que esté la máquina. Esto significa a.out para 2.2 y a.out o ELF para 3.0 dependiendo de lo que devuelva la variable `objformat`. De la misma manera, una vez se mueven las librerías a un subdirectorio, ya no será posible compilar librerías a.out. Si un port sólo funciona para a.out, definir BROKEN_ELF. Estos ports serán pasados por alto durante la compilación en sistemas ELF. <makevar>PORTOBJFORMAT</makevar> bsd.port.mk definirá PORTOBJFORMAT a aout o elf y lo exportará en las variables de entorno CONFIGURE_ENV, SCRIPTS_ENV y MAKE_ENV. (Siempre será aout en 2.2-STABLE). También se pasa a PLIST_SUB como PORTOBJFORMAT=${PORTOBJFORMAT}. (Consultar los comentarios sobre ldconfig de las líneas anteriores). La variable se defina usando esta línea en bsd.port.mk: PORTOBJFORMAT!= test -x /usr/bin/objformat && /usr/bin/objformat || echo aout Los procesos de compilación de los ports deberían usar esta variable para decidir que hacer. De todas maneras, si el script configure del port detecta automáticamente un sistema ELF, no es necesario hacer referencia a PORTOBJFORMAT. pkgname a pkgname a pkgname a pkgname a pkgname a pkgname a