Paketbaurichtlinien für Tcl

Diese Konventionen gelten für Tcl-Pakete in Fedora 9 und späteren Versionen. Einige Aspekte von Tcl in Fedora 7 und Fedora 8 stehen im Widerspruch zu diesen Richtlinien.

Namenskonventionen

Alle Tcl/Tk-Erweiterungen müssen mit dem Präfix tcl- benannt werden. Dies gilt auch für Tcl/Tk-Pakete, deren Name bereits mit tcl beginnt (siehe Beispiele unten). Optional wird die Angabe Provides: foo empfohlen, um die Auswahl des Pakets anhand des Upstream-Namens zu ermöglichen, sofern dieser nicht zu allgemein ist und nicht mit einem bestehenden Paketnamen kollidiert. Tk-Erweiterungen können zusätzlich Provides:` mit dem Präfix `+tk- hinzufügen. + Beispiele:

Name: tcl-bwidget
Provides: bwidget = %{version}-%{release}, tk-bwidget = %{version}-%{release}

Name: tcl-tclxml
Provides: tclxml = %{version}-%{release}

Name: tcl-thread

Eine Ausnahme von dieser Namensregel bilden bestehende Pakete, die sowohl eine Erweiterung als auch eine Shell bereitstellen, wie beispielsweise expect. Beachten Sie jedoch, dass von der Bereitstellung einer Shell dringend abgeraten wird (siehe unten).

Anwendungen

Tcl- und Tk-Anwendungen müssen in der Shebang-Zeile einen nicht-versionierten Interpreternamen verwenden. Dadurch werden unnötige Abhängigkeiten von der verwendeten Interpreterversion vermieden. Die meisten Abhängigkeiten betreffen spezifische Tcl-Erweiterungen, nicht die Befehlszeilenanwendungen selbst. Benötigt eine Anwendung dennoch eine bestimmte Tcl-Version, muss sie dies über das Standard-Tcl-Paketsystem angeben und zusätzlich in der Spec-Datei explizit Requires: tcl(abi) = 8.x hinzufügen.

Schlecht:

#!/usr/bin/tclsh8.5

Gut:

#!/usr/bin/tclsh
package require -exact Tcl 8.5

Für Tk-Anwendungen gelten dieselben Regeln. Der nicht-versionierte Interpretername wish muss verwendet werden.

Erweiterungen

Seit Fedora 9 wurden %{_libdir} und %{_datadir} aus dem Suchpfad entfernt, um die Ladezeiten von Paketen zu optimieren. Stattdessen müssen Tcl-Erweiterungspakete in %{_datadir}/tcl8.x installiert werden, wenn es sich um architekturunabhängige Pakete handelt, die ausschließlich Tcl-Code enthalten, oder in %{_libdir}/tcl8.x, wenn es sich um architekturspezifische Erweiterungen mit gemeinsam genutzten Bibliotheken handelt. Beachten Sie, dass die meisten Tcl-Erweiterungen nicht standardmäßig für die Installation in diesen Verzeichnissen konfiguriert sind und möglicherweise zusätzliche Konfigurationsoptionen, Patches oder Skriptcode in %install benötigen, um die Dateien an den richtigen Ort zu verschieben.

Sowohl architekturspezifische als auch noarch-Erweiterungen für Tcl müssen Folgendes verwenden:

Requires: tcl(abi) = 8.6

Dies ist erforderlich, um anzugeben, mit welcher Tcl-Version (8.5 in F19 und F20, 8.6 in F21+) die Erweiterungen kompiliert wurden, da die folgenden Richtlinien die Installation von Erweiterungen in Tcl-Versionsverzeichnissen vorschreiben, die nur von einer einzigen Tcl-Version verwendet werden. Dies führt zwar zu der Unannehmlichkeit, dass alle architekturspezifischen und nicht-architekturspezifischen Erweiterungen für eine neue Tcl-Nebenversion neu kompiliert werden müssen,. Da neue Tcl-Nebenversionen jedoch nur alle paar Jahre erscheinen, sollte dies kein allzu großes Problem darstellen.

Architekturunabhängige (noarch-) Pakete

Die folgenden Makros müssen am Anfang der Spec-Datei verwendet werden, um die korrekten Installationspfade zu ermitteln:

%{!?tcl_version: %global tcl_version %(echo 'puts $tcl_version' | tclsh)}
%{!?tcl_sitelib: %global tcl_sitelib %{_datadir}/tcl%{tcl_version}}

Damit die Makros funktionieren, muss das Paket außerdem BuildRequires: tcl entweder direkt oder indirekt mit BuildRequires: tcl-devel einbinden.

Das bloße Hinzufügen von %{tcl_sitearch} und %{tcl_sitelib} reicht nicht aus, um sicherzustellen, dass die Pakete am richtigen Ort installiert werden. Die meisten Tcl-Erweiterungen werden standardmäßig in %{_libdir} installiert. Es gibt zwei Möglichkeiten, dies zu ändern. Für die meisten noarch-Pakete können Sie die Konfigurationsoptionen --libdir und --datadir verwenden, um das Installationsverzeichnis zu ändern:

%configure --libdir=%{tcl_sitelib} --datadir=%{tcl_sitelib}

Für noarch-Pakete, die nicht durch die Verwendung von --libdir korrigiert werden, können Sie einfach das Installationsverzeichnis im Abschnitt %install der Spec-Datei verschieben.

%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}

Es kann auch akzeptabel sein, das configure-Skript und das Makefile des Upstream-Projekts zu patchen, um zusätzliche Flexibilität für das Installationsverzeichnis zu ermöglichen, aber der Paketierer ist nicht dazu verpflichtet.

Architekturabhängige Pakete

Die folgenden Makros müssen am Anfang der Spec-Datei verwendet werden, um die korrekten Installationspfade zu ermitteln:

%{!?tcl_version: %global tcl_version %(echo 'puts $tcl_version' | tclsh)}
%{!?tcl_sitearch: %global tcl_sitearch %{_libdir}/tcl%{tcl_version}}

Damit die Makros funktionieren, muss das Paket außerdem BuildRequires: tcl entweder direkt oder indirekt mit BuildRequires: tcl-devel einbinden.

Während %{tcl_sitearch} in Fedora 8 und früheren Versionen ein Symlink zu %{tcl_sitelib} ist, handelt es sich in Fedora 9 um ein tatsächliches Verzeichnis.

Oft kann das korrekte Installationsverzeichnis mit dem Flag --libdir des configure-Skripts festgelegt werden:

%build
%configure --libdir=%{tcl_sitearch}

Bei den meisten architekturspezifischen Paketen wird das Flag --libdir im configure-Skript auch verwendet, um tclConfig.sh zu finden. Einige dieser architekturspezifischen Pakete funktionieren nicht mehr, wenn --libdir auf %{tcl_sitearch} umgeleitet wird. Für Pakete, die keine alternativen Werte für --libdir verarbeiten können, können Sie einfach das Installationsverzeichnis im Abschnitt %install der Spec-Datei verschieben:

%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}

Architekturspezifische Pakete lassen sich im Allgemeinen in drei Kategorien einteilen: solche, die eine Shell bereitstellen, solche, die eine fooConfig.sh-Datei und eine gemeinsam genutzte Bibliothek zum Verlinken bereitstellen, und solche, die nur eine gemeinsam genutzte Bibliothek für dlopen() bereitstellen.

Keine Shells: Nur sehr wenige Tcl-Erweiterungspakete stellen eine Shell bereit. Es ist unüblich, eine Shell für eine Erweiterung bereitzustellen. Die gemeinsam genutzte Bibliothek der Erweiterung kann dynamisch über den Standardmechanismus package require ... in einen Tcl-Interpreter geladen werden, ohne dass eine Shell bereitgestellt werden muss, die die gemeinsam genutzte Bibliothek automatisch lädt. Ausnahmen von dieser Regel bilden die Shells, die üblicherweise auf einem System erwartet werden, darunter Tk (wish) und Expect (expect, expectk).

-devel-Teilpaket für fooConfig.sh: Einige architekturspezifische Tcl-Erweiterungen stellen eine gemeinsam genutzte Bibliothek und eine zugehörige fooConfig.sh-Datei mit Anweisungen zum Verlinken der Bibliothek bereit. Die gemeinsam genutzte Bibliothek für solche Pakete muss in %{_libdir} installiert werden, damit sie von Anwendungen, die sie verlinken, zur Laufzeit gefunden werden kann. Leider verweist die Datei pkgIndex.tcl im Paketverzeichnis häufig mit einem relativen Pfad auf die gemeinsam genutzte Bibliothek. Es gibt zwei Möglichkeiten, dies zu beheben. Erstens kann der Paketbetreuer das Installationsverzeichnis %{_libdir} beibehalten und einen symbolischen Link zu %{tcl_sitearch} erstellen. Zweitens kann der Paketbetreuer die Datei pkgIndex.tcl so anpassen, dass sie den korrekten Pfad zur gemeinsam genutzten Bibliothek enthält. Beide Lösungen sind akzeptabel.

Die Dateien fooConfig.sh müssen in einem -devel-Teilpaket abgelegt werden. Unter Umständen sind einige Anpassungen mit sed erforderlich, um die Datei fooConfig.sh so zu modifizieren, dass die Pfade zu den Bibliotheken und Headern weiterhin korrekt sind.

Keine mit dlopen() geladenen Bibliotheken in %{_libdir}: Wenn die Erweiterung keine fooConfig.sh-Datei bereitstellt, darf die gemeinsam genutzte Bibliothek nicht direkt in %{_libdir} installiert werden, sondern muss im paketspezifischen Installationsverzeichnis in %{tcl_sitearch} abgelegt werden. Dies kann einen Patch erfordern, um die pkgIndex.tcl-Datei der Erweiterung so zu aktualisieren, dass sie die gemeinsam genutzte Bibliothek am richtigen Ort sucht.

Stubs sind in Ordnung, wenn sie in einem -devel-Teilpaket abgelegt werden: Einige Tcl-Erweiterungen stellen eine statische „Stub“-Bibliothek bereit. Stub-Bibliotheken sind eine Besonderheit von Tcl, die versionsunabhängiges dynamisches Linken auf verschiedenen Plattformen ermöglicht. Es handelt sich dabei nicht um normale statische Bibliotheken, die die eigentliche Funktionalität der Bibliothek bereitstellen, sondern um eine Indirektionsebene, die auf die gemeinsam genutzte Bibliothek verweist. Diese Stub-Bibliotheken haben nicht die gleichen Probleme mit statischem Linken, die unter Fedora generell unerwünscht sind, und sind daher akzeptabel. Wenn ein Paket eine solche Stub-Bibliothek bereitstellt, muss diese in einem -devel-Teilpaket abgelegt werden. Weitere Informationen zu Stubs finden Sie im Tcl-Wiki.

Want to help? Learn how to contribute to Fedora Docs ›