Politica de empaquetamiento Tcl
De Wiki de la Comunidad Mandriva
Estas convenciones se aplican a los paquetes Tcl de Mandriva Linux 2009 Spring y posteriores (y a Cooker a partir de la disponibilidad de Tcl / Tk 8.6 el 04/12/2008). Versiones anteriores siguieron políticas no muy claras; los modulos Tcl / Tk se situaban en cualquier lugar dentro de /usr/lib o /usr/lib64 que les funcionara. Las normas discutidas en estas políticas han sido o serán provistas para Mandriva Linux 2008 Spring y Mandriva Linux 2009 en los paquetes actualizados del repositorio /backports, así los paquetes basados en Tcl puede ser sencillamente traídos al repositorio backports desde las versiones Cooker sin muchos problemas.
Contenido |
Convensiones sobre Nombres
Los nombres de todas las extensiones Tcl/Tk deben estar precedidas por tcl-. El resto del nombre deberá basarse en el nombre del modulo (y no el nombre del archivo tar upstream -¿original?-), en minusculas si es necesario. Así si el nombre del archivo tar original monkeys provee una extensión Tcl llamada nuts, el paquete Tcl se debera llamar tcl-nuts. Estas normas aplican incluso a los paquetes Tcl/Tk que tegan el prefijo tcl en el nombre (vea el ejemplo posterior). Opcionalmente Provides: foo se recomienda para permitir seleccionar el paquete por su nombre original, mientras el nombre original no sea excesivamente generico y no genere conflictos con los nombres de paquete existentes. También se puede añadir Provides: con el nombre original del archivo tar si difiere del nombre del modulo Tcl. Las extensiones Tk tienen la opción de añadir Provides: adicionales con el prefijo tk-.
Ejemplos:
Name: tcl-bwidget
Provides: bwidget = %{version}-%{release}, tk-bwidget = %{version}-%{release}
Name: tcl-tclxml
Provides: tclxml = %{version}-%{release}
Name: tcl-thread
La excepción a esta politica son los paquetes existentes que proveen tanto de extensiones y un shell (¿interprete?), entre ellos expect. De cualquier forma, note que es altamente recomendado no proveer un shell (vea a continuación). Si una extensión Tcl se provee como parte de otro paquete más grande tampoco se aplicaran las reglas, pero en general, las extensiones Tcl deberian dividirse en un paquete separado en estos casos.
Aplicaciones
Las extensiones Tcl y Tk deberían utilizar un interprete sin versión. Esto evitara dependencias innecesarias a una versión especifica del interprete. La mayoria de las dependencia son con alguna extensión Tcl especifica, no de las aplicaciones de linea de comandos. Incluso si una aplicación requiere de una versión especifica de Tcl, se debera usar el sistema package estandar de Tcl para expresarlo.
Mal:
#!/usr/bin/tclsh8.6
Bien:
#!/usr/bin/tclsh package require -exact Tcl 8.6
Las mismas reglas aplican a las aplicaciones Tk. Se deberá usar el nombre sin versión del interprete wish.
Extensiones
En Mandriva Linux 2009 y anteriores, Tcl buscaba las extensiones en todos los subdirectorios dentro de: %{_libdir} y %{_prefix}/lib. En Mandriva Linux 2009 Spring, %{_libdir} y %{_prefix}/lib se han eliminado de la trayectoria de busqueda para optimizar el tiempo de carga del paquete. Las paquetes de las extensiones Tcl deberán instalarse en %{_datadir}/tcl8.x si son paquetes no dependientes de la arquitectura que contengan solamente codigo Tcl, o en %{_libdir}/tcl8.x si son extensiones para una arquitectura especifica que contegan librerias compartidas. Note que la mayoria de las extensiones Tcl no se instalan de serie en esos directorios, y pude requerir de opciones (switches) adicionales, parches o scripts dentro de %install para mover los archivos a su correcta localización.
Note que esto provoca que todos los paquetes que provven un modulo Tcl necesiten recompilarse para cada versión menor nueva de Tcl - 8.7 vs. 8.6, por ejemplo - pero es una molestia relativamente menor, y se requerian de otros arreglos en la misma situación de cualquier modo.
Macros
El paquete libtcl-devel (o lib64tcl-devel), desde la versión 8.6, provee de tres importantes macros:
%tcl_version %tcl_sitelib %tcl_sitearch
%tcl_version nos dice la versiones mayor/menor actuales.
%tcl_sitelib es la trayectoria correcta para extensiones Tcl independientes de la arquitectura: por ejemplo, actualmente regresa {{archivo|/usr/share/tcl8.6}.
%tcl_sitearch es la trayectoria correcta para extensiones Tcl dependientes de la arquitectura: por ejemplo, actualmente regresa /usr/lib/tcl8.6 o /usr/lib64/tcl8.6 , dependiendo de la arquitectura que se use.
Todos los paquetes deberán utilizar estas macros en vez de intentar proveer por su cuenta la misma información, o crear los directorios como %{_datadir}/tcl8.6 o similares. Note que debido a que las macros se proveen en el paquete -devel, incluso los paquetes Tcl que no requieren compilación deberán contener BuildRequire tcl-devel.
paquetes noarch(no dependientes de arquitectura)
Añadir solamente %{tcl_sitearch} y %{tcl_sitelib} no es suficiente para asegurarse que los paquetes se instalan en las trayectorias adecuadas. La mayoria de las extensiones Tcl se instalan en %{_libdir} por omisión. Hay dos maneras de cambiar eso. Para la mayoria de los paquetes noarch, puede utilizar las opciones de configue --libdir and --datadir para cambiar el directorio de instalación:
%configure2_5x --libdir=%{tcl_sitelib} --datadir=%{tcl_sitelib}
Para los paquetes noarch que no se pueden modificar utilizando --libdir, simplemente cambie el directorio de instalación en la sección %install del archivo spec.
%install
rm -rf %{buildroot}
%makeinstall_std
install -d %{buildroot}%{tcl_sitelib}
mv %{buildroot}%{_datadir}/foobar%{version} %{buildroot}%{tcl_sitelib}/foobar%{version}
También es aceptable parchar el script configure y Makefile originales para añadir flexibilidad adicional para el directorio de instalación, pero el empaquetador no esta obligado a hacerlo.
paquetes de arquitecturas especificas
La opción --libdir del script configure se suele utilizar para indicar la trayectoria de instalación correcta:
%build
%configure2_5x --libdir=%{tcl_sitearch}
Para los paquetes que no responden apropiadamente a los valores alternos de --libdir, simplemente cambie el directorio de instalación dentro de la sección %install del archivo spec:
%install
rm -rf %{buildroot}
%makeinstall_std
install -d %{buildroot}%{tcl_sitearch}
mv %{buildroot}%{_libdir}/foobar%{version} %{buildroot}%{tcl_sitearch}/foobar%{version}
También es aceptable parchar el script configure y Makefile originales para añadir flexibilidad adicional para el directorio de instalación, pero el empaquetador no esta obligado a hacerlo.
Los paquetes de arquitectura especifica generalmente se pueden agrupar en tres categorías: los que proveen un shell (¿interprete?), los que proveen un archivo fooConfig.sh y una librería de enlace compartida, y los que solo proveen de una librería compartida para dlopen().
Sin shells
Muy pocas extensiones de Tcl proveen un shell. No se recomienda proveer un shell para una extensión. La librería de extensiones compartidas se puede cargar dinamicamnet dentro del interprete Tcl por medio del mecanismo estandard package require ... sin proveer un shell que automáticamente cargue la librería compartida. Las exepciones a esta regla son los shell que se espera esten presentes en el sistema, esto incluye el de Tk (wish) y el de Expect (expect, expectk).
sub-paquete -devel para fooConfig.sh
Algunas extensiones Tcl dependientes de la arquitectura proporcionan una librería compartida y el correspondiente archivo fooConfig.sh con instrucciones para enlazar a la librería. La librería compartida para estos paquetes debe instalarse dentro de %{_libdir} para poder ser encontrada al momento de la ejecución de aplicaciones que la necesiten. Desafortunadamente, el archivo pkgIndex.tcl proporciona referencias a la librería compartida por medio de trayectorias relativas. Existen dos formas de arreglar esto. Primero, el mantenedor puede elegir conservar %{_libdir} como directorio de instalación, y hacer un enlace simbólico a %{tcl_sitearch}. Segundo, el mantenedor puede cambiar(patch) el archivo pkgIndex.tcl para que contenga la trayectoria adecuada a la librería compartida. Cualquiera de las soluciones son aceptables..
Los archivos fooConfig.sh deben colocarse en un sub-paquete -devel . Esto puede requerir usos mágicos de sed para modificar el archivo fooConfig.sh para que las trayectorias a las librerías y cabeceras continúen correctas.
Librerías que no deben ir en %{_libdir}
Si la extensión no proporciona un archivo fooConfig.sh, entonces la libreria compartida no debe instalarse directamente en %{_libdir} , si no en el directorio especifico del paquete en %{tcl_sitearch}. Esto puede requerir un cambio(patch) para actualizar el archivo pkgIndex.tcl de la extensión para que busque la libreria compartida en el sitio adecuado.
Librerías Stub aceptables si son puestas en un sub-paquete -devel
Algunas extensiones Tcl proporcionan una librería estática 'stub'. Las librerías Stub son un Tcl-ismo para proporcionar librerías de enlace dinámico independiente de versión en una variedad de plataformas. Estas no son librerías estáticas normales, proporciona un nivel de indirección al apuntar a la librería compartida. Estas librerías stub no tienen los mismos indeseables problemas para enlazarse estaticamente, y por lo tanto son aceptables. Si un paquete proporciona una librería stub , debe colocarse en un sub-paquete -devel. Mayor información sobre las librerías stub se encuentra en el wiki de Tcl .
