Directrices de empaquetado de Tcl
Estas convenciones se aplican a los paquetes Tcl en Fedora 9 y versiones posteriores. Algunos aspectos de Tcl en Fedora 7 y Fedora 8 entran en conflicto con estas directrices.
Convenciones de Nombrado
El nombre de todas las extensiones Tcl/Tk debe tener el prefijo tcl-. Esta regla se aplica incluso a los paquetes Tcl/Tk que ya tienen el prefijo tcl en el nombre (consulte ejemplos a continuación). Se recomienda añadir Provides: algo opcional para permitir la selección del paquete según el nombre original, siempre que este no sea excesivamente genérico ni entre en conflicto con el nombre de un paquete existente. Las extensiones Tk pueden añadir Provides: adicionales con el prefijo tk-. + Ejemplos:
Nombre: tcl-bwidget
Proveedores: bwidget = %{version}-%{release}, tk-bwidget = %{version}-%{release}
Nombre: tcl-tclxml
Proveedores: tclxml = %{version}-%{release}
Nombre: tcl-thread
La excepción a esta regla de nomenclatura son los paquetes existentes que proporcionan tanto una extensión como un intérprete, tal como expect. Sin embargo, tenga en cuenta que se desaconseja encarecidamente proporcionar un intérprete (shell) (consulte más adelante).
Aplicaciones
Las aplicaciones Tcl y Tk deben usar un nombre de intérprete sin versión en la línea “shebang”. Esto evita cualquier dependencia innecesaria de la versión del intérprete utilizado. La mayoría de las dependencias corresponden a extensiones específicas de Tcl, no a las aplicaciones de línea de instrucciones. Sin embargo, si una aplicación requiere una versión específica de Tcl, debe usar el sistema de paquetes estándar de Tcl para expresarlo, así como un Requires: tcl(abi) = 8.x explícito en el archivo de especificaciones.
Malo:
#!/usr/bin/tclsh8.5
Bueno:
#!/usr/bin/tclsh package require -exact Tcl 8.5
Las mismas reglas se aplican para las aplicaciones Tk. Se debe utilizar el nombre de intérprete wish sin versión.
Extensiones
Desde Fedora 9, %{_libdir} y %{_datadir} se han eliminado de la ruta de búsqueda para optimizar los tiempos de carga de los paquetes. En su lugar, los paquetes de extensión Tcl deben instalarse en %{_datadir}/tcl8.x si son paquetes de 'noarch' que contienen solo código Tcl, o en %{_libdir}/tcl8.x si son extensiones específicas de la arquitectura que contienen bibliotecas compartidas. Tenga en cuenta que la mayoría de las extensiones Tcl no están configuradas; se instalan en estos directorios de fábrica y podrían requerirse opciones de configuración adicionales, parches o código en script en %install para mover los archivos al lugar correcto.
Ambas especificaciones de arquitectura y extensiones noarch de Tcl deben utilizar
Requiere: tcl(abi) = 8.6
para indicar cual versión de Tcl (8.5 en F19 y F20, 8.6 en F21+) frente a la cual fue compilada. Esto es necesario porque las líneas de guía a continuación requiere extensiones para ser instaladas en directorios tcl-versionados, lo cual están solo utilizados por una versión única de Tcl. Esto no impone una inconveniencia que todas las especificaciones de arquitectura y extensiones sin arquitectura necesitarán para ser recompilados para una versión menor nueva de Tcl, pero desde el espejo nuevo de Tcl solo aparece una vez cada pocos años, esto no sería tal como una inconveniencia problemática.
paquetes sin arquitectura
Las macros siguientes deben ser utilizadas en la cima del archivo específico para determinar las rutas de instalación correctas:
%{!?tcl_version: %global tcl_version %(echo 'puts $tcl_version' | tclsh)}
%{!?tcl_sitelib: %global tcl_sitelib %{_datadir}/tcl%{tcl_version}}
Con el fin de las macros funcionen, el paquete debe además ser BuildRequires: tcl incluso directamente, o indirectamente con BuildRequires: tcl-devel
Simplemente no es suficiente agregar %{tcl_sitearch} y %{tcl_sitelib} para garantizar que los paquetes se instalen en el lugar correcto. Por defecto, la mayoría de las extensiones de Tcl se instalarán en %{_libdir}. Hay dos maneras para cambiar esto. Para la mayoría de los paquetes noarch, puede usar los parámetros de configuración --libdir y --datadir para cambiar el directorio de instalación:
%configure --libdir=%{tcl_sitelib} --datadir=%{tcl_sitelib}
Para los paquetes noarch que no estén fijados utilizando --libdir*`, simplemente puede mover el directorio de instalación dentro de la sección `%install+ del archivo específico.
%install
rm -rf $RPM_BUILD_ROOT
make install DESTDIR=$RPM_BUILD_ROOT
install -d $RPM_BUILD_ROOT%{tcl_sitelib}
mv $RPM_BUILD_ROOT%{_datadir}/foobar%{version} $RPM_BUILD_ROOT%{tcl_sitelib}/foobar%{version}
También puede ser aceptable parchar el upstream del guion configure y Makefile para agregar flexibilidad adicional al directorio de instalación, pero no es necesario que el empaquetador haga esto.
paquetes específicos de arquitectura
Las macros siguientes deben ser utilizadas en la cima del archivo específico para determinar las rutas de instalación correctas:
%{!?tcl_version: %global tcl_version %(echo 'puts $tcl_version' | tclsh)}
%{!?tcl_sitearch: %global tcl_sitearch %{_libdir}/tcl%{tcl_version}}
Con el fin de las macros funcionen, el paquete debe además ser BuildRequires: tcl incluso directamente, o indirectamente con BuildRequires: tcl-devel
Mientras %{tcl_sitearch} es un enlace simbólico a %{tcl_sitelib} en Fedora 8 y anteriores, en Fedora 9 es un directorio actual.
El indicador --libdir para el guion de configuración puede a menudo ser utilizado para fijar el directorio correcto de instalación:
%build
%configure --libdir=%{tcl_sitearch}
Para la mayoría de los paquetes específicos de la arquitectura, el indicador --libdir del guion de configuración también se usa para localizar tclConfig.sh. Algunos de estos paquetes específicos de la arquitectura fallarán si --libdir se redirige a %{tcl_sitearch}. Para los paquetes que no admiten valores alternativos para --libdir, simplemente puede mover el directorio de instalación en la sección %install del archivo de especificaciones:
%install
make install DESTDIR=$RPM_BUILD_ROOT
install -d $RPM_BUILD_ROOT%{tcl_sitearch}
mv $RPM_BUILD_ROOT%{_libdir}/foobar%{version} $RPM_BUILD_ROOT%{tcl_sitearch}/foobar%{version}
Los paquetes específicos de Arch se pueden agrupar generalmente en tres categorías: aquellos que proporcionan un intérprete, aquellos que proporcionan un archivo fooConfig.sh y una biblioteca compartida para vincular, y aquellos que solo proporcionan una biblioteca compartida para dlopen().
Sin intérpretes:
Muy pocos paquetes de extensión Tcl proporcionan un intérprete. Proporcionar un intérprete para una extensión está mal visto. La biblioteca compartida de la extensión se puede cargar dinámicamente en un intérprete Tcl mediante el mecanismo estándar package require ... sin necesidad de un intérprete que cargue automáticamente la biblioteca compartida. Las excepciones a esta regla son los intérpretes que se espera que estén presentes en un sistema, como Tk (wish) y Expect (expect, expectk).
Subpaquete -devel para fooConfig.sh:
Algunas extensiones Tcl específicas de la arquitectura proporcionan una biblioteca compartida y el archivo fooConfig.sh correspondiente con instrucciones para enlazar con ella. La biblioteca compartida para estos paquetes debe instalarse en %{_libdir} para que las aplicaciones que enlazan con ella puedan encontrarla en tiempo de ejecución. Desafortunadamente, el archivo pkgIndex.tcl en el directorio del paquete suele referenciar la biblioteca compartida con una ruta relativa. Hay dos maneras de solucionar esto. Primero, el responsable puede optar por mantener el directorio de instalación como %{_libdir} y crear un enlace simbólico a %{tcl_sitearch}. Segundo, el responsable puede parchear el archivo pkgIndex.tcl para que contenga una ruta adecuada a la biblioteca compartida. Cualquiera de las dos soluciones es aceptable.
Los archivos fooConfig.sh deben incluirse en un subpaquete -devel. Esto puede requerir la modificación de fooConfig.sh para que las rutas de las bibliotecas y los encabezados sigan siendo correctas.
No hay bibliotecas con dlopen() en %{_libdir}:
Si la extensión no proporciona un archivo fooConfig.sh, entonces la biblioteca compartida no debe instalarse directamente en %{_libdir}, sino en el directorio de instalación específico del paquete en %{tcl_sitearch}. Esto podría requerir un parche para actualizar el archivo pkgIndex.tcl de la extensión para que busque la biblioteca compartida en el lugar correcto.
Los resguardos son correctos si pone dentro de subpaquete -devel: Algunas extensiones Tcl proporcionan una biblioteca 'stub' (resguardo) estática. Las bibliotecas resguardadas son un Tcl-ismo para proporcionar enlaces dinámicos independientes de la versión en una variedad de plataformas. Estas no son bibliotecas estáticas normales que proporcionan la funcionalidad real de la biblioteca, sino que proporcionan un nivel de indirección que apunta a la biblioteca compartida. Estas bibliotecas resguardadas no tienen los mismos problemas de enlaces estáticos que generalmente están mal vistos en Fedora y, por lo tanto, son aceptables. Si un paquete proporciona una biblioteca resguardada, debe incluirse en un subpaquete '-devel'. Puede encontrar más información sobre resguardos en la wiki de Tcl: https://wiki.tcl-lang.org/page/Stubs
Want to help? Learn how to contribute to Fedora Docs ›