Paketierung von Add-Ons für GNU Emacs

Zweck

Ziel dieses Dokuments ist es, bewährte Verfahren beim Paketieren von Add-ons für GNU Emacs zu fördern und die Einreichung weiterer Emacs-Add-on-Pakete zur Paketsammlung durch die Bereitstellung einfach zu verwendender Spec-Datei-Vorlagen zu unterstützen.

Wichtige Anmerkungen zu diesen Richtlinien

Die Richtlinien in den folgenden Abschnitten nutzen ausgiebig die in /usr/lib/rpm/macros.d/macros.emacs definierten Makros, die mit dem Paket emacs-common installiert werden.

Es gibt zwei unterschiedliche Fälle, in denen die Berücksichtigung dieser Richtlinien erforderlich ist:

  1. Der erste Fall beschreibt eine Situation, in der ein Paket primär dazu dient, Emacs zusätzliche Funktionen bereitzustellen, und ohne Emacs nutzlos ist. Ein Beispiel hierfür ist der E-Mail-Reader für virtuelle Maschinen, der im Paket emacs-vm enthalten ist. Im Folgenden bezeichnen wir dies als Fall 1.

  2. Der zweite Fall beschreibt die Situation, in der die Hauptfunktionalität eines Pakets Emacs nicht erfordert, das Paket aber zusätzlich einige Elisp-Dateien enthält, um die Unterstützung des Pakets in Emacs zu gewährleisten. Im Folgenden bezeichnen wir dies als Fall 2.

Benennung von Paketen und Organisieren der Teilpakete

Fall 1

Wenn es sich bei einem Paket in erster Linie um ein Add-on für Emacs handelt, sollte das Hauptpaket emacs-foo heißen.

Fall 2

Wenn die Hauptfunktionalität eines Pakets Emacs nicht erfordert, das Paket aber zusätzlich Elisp-Dateien zur Unterstützung in Emacs enthält, sollten diese im Hauptpaket enthalten sein, welches das Paket emacs-filesystem über Requires einbinden muss. Weitere Details folgen.

Paketinhalt

Fall 1

Dateien, die speziell für GNU Emacs benötigt werden, sollten im Hauptpaket emacs-foo abgelegt werden. Dieses sollte den Elisp-Quellcode, kompiliertes Elisp und alle weiteren Dateien enthalten, die für die Verwendung des Pakets oder Teilpakets mit GNU Emacs erforderlich sind.

Fall 2

Der kompilierte Elisp-Quellcode und die Elisp-Quelldateien sollten als Teil des Hauptpakets paketiert und nicht in separate Pakete aufgeteilt werden.

Dateiorte

Dateispeicherorte für GNU Emacs Add-on-(Teil-)Pakete:

  • Alle Elisp- und zugehörigen Dateien für das Paket sollten im Verzeichnis %{_emacs_sitelispdir}/foo installiert werden.

  • Falls das Paket eine Startdatei benötigt, sollte diese foo-init.el heißen und in %{_emacs_sitestartdir} abgelegt werden.

„Requires“ des Pakets

Fall 1

Paket-Requires für GNU Emacs-Add-on-(Teil-)Pakete:

  • Wo relevant, muss emacs-foo den Eintrag Requires: emacs-common-foo = %{version}-%{release} enthalten

  • emacs-foo muss den Eintrag Requires: emacs(bin)%{?_emacs_version: >= %{_emacs_version}} haben

Fall 2

Wenn das Paket Hilfsdateien zur Verwendung mit GNU Emacs enthält, muss es die Zeile Requires: emacs-filesystem >= %{_emacs_version} enthalten

„BuildRequires“ des Pakets

BuildRequires für GNU Emacs add-on-Pakete:

  • Im Allgemeinen sollte es ausreichen, BuildRequires: emacs-nw anzugeben

Manuelle Byte-Kompilierung

Die Elisp-Kompilierung eines Pakets erfolgt üblicherweise über ein mitgeliefertes Makefile. Gelegentlich kann es jedoch erforderlich sein, dem %build-Abschnitt der Spec-Datei Befehle zur Byte-Kompilierung hinzuzufügen. Verwenden Sie in diesem Fall %{_emacs_bytecompile} file.el.

Alle Elisp-Dateien müssen bytekompiliert und paketiert werden, es sei denn, es gibt einen triftigen Grund, dies nicht zu tun. In diesem Fall sollte dies mit einem Kommentar in der Spec-Datei dokumentiert werden.

Verwendung von „BuildArch: noarch“

Wenn ein Add-on-Paket lediglich die Byte-Kompilierung von Elisp erfordert, sollte BuildArch: noarch verwendet werden. Dies dürfte im Fall 2 höchstwahrscheinlich nie zutreffen.

Beispielvorlage für eine Spec-Datei

Vorlage für ein Add-on-Paket für GNU Emacs (Fall 1)

Dies ist eine Vorlage für ein Paket für GNU Emacs. Das Hauptpaket heißt emacs-foo und enthält alle Dateien, die zum Ausführen des Pakets foo mit GNU Emacs benötigt werden. Dazu gehören sowohl kompilierte Elisp-Dateien als auch Elisp-Quelldateien.

%global pkg foo
%global pkgname Foo

Name:           emacs-%{pkg}
Version:
Release:        %autorelease
Summary:

Group:
License:
URL:
Source0:

BuildArch:      noarch
BuildRequires:  emacs-nw
Requires:       emacs(bin)%{?_emacs_version: >= %{_emacs_version}}

%description
%{pkgname} is an add-on package for GNU Emacs. It does wonderful things...


%prep
%autosetup -n %{pkg}-%{version}

%build


%install


%post


%preun


%files
%doc
%{_emacs_sitelispdir}/%{pkg}
%{_emacs_sitestartdir}/*.el


%changelog
%autochangelog

Vorlage für ein Paket, das Hilfsdateien für GNU Emacs enthält (Fall 2)

Dies ist ein Grundgerüst eines Pakets, das auch Unterstützungsdateien für GNU Emacs enthält:

Name:           foo
Version:
Release:        %autorelease
Summary:

Group:
License:
URL:
Source0:

BuildRequires:  emacs-nw
Requires:       emacs-filesystem%{?_emacs_version: >= %{_emacs_version}}

%description
Foo is a package which contains auxiliary Emacs support files.


%prep
%autosetup

%build


%install


%post


%preun


%files
%doc
%{_emacs_sitelispdir}/foo
%{_emacs_sitestartdir}/*.el

%changelog
%autochangelog

Prinzipien hinter den Richtlinien

Ort der installierten Dateien

Die Dateien für das Add-on-Paket foo sollten in %{_emacs_sitelispdir}/foo abgelegt werden, was zu /usr/share/emacs/site-lisp/foo aufgelöst wird.

Normalerweise benötigt ein Add-on-Paket eine Startdatei, die foo-init.el heißen und in %{_emacs_sitestartdir} abgelegt werden sollte, was zu /usr/share/emacs/site-lisp/site-start.d/ aufgelöst wird.

Paketierung von Elisp-Quelldateien

Ein Emacs-Add-on-Paket wird üblicherweise aus Elisp-Quelldateien kompiliert. Die kompilierten Elisp-Dateien werden dann dem entsprechenden emacs-foo-Paket beigefügt. Es ist aus mehreren Gründen wichtig, auch die Elisp-Quelldateien einzubinden. Beispielsweise kann der Elisp-Debugger beim Debuggen eines Problems mit einem Emacs-Paket in der Quelldatei nach dem relevanten Code oder der Symboldefinition suchen, sofern diese vorhanden ist. Außerdem ist es manchmal hilfreich, direkt zu einer Variablenbeschreibung aus der Emacs-Hilfe zu springen.

BuildArch für Emacs add-on-Pakete

Sie sollten BuildArch: noarch für Add-on-Pakete festlegen, die während des Bauprozesses nur Elisp-Dateien kompilieren.

Falls der Paketbauprozess auch Programme in anderen Sprachen kompiliert, müssen Sie möglicherweise BuildArch nicht festlegen.

„Requires“ für GNU Emacs

Add-on-Pakete sollten die entsprechenden Requires-Einträge für die jeweilige Emacs-Variante enthalten. GNU Emacs ist in mehreren Paketen verfügbar – einige Details zu diesen Paketen folgen.

  1. Das Paket emacs wurde mit reiner GTK-Unterstützung entwickelt, um dem Benutzer die Ausführung von Emacs in einer Fensterumgebung zu ermöglichen.

  2. Das Paket emacs-gtk+x11 wurde mit X11-Unterstützung über das GTK-Toolkit erstellt, um dem Benutzer die Ausführung von Emacs in einer Fensterumgebung zu ermöglichen.

  3. Das Paket emacs-lucid wurde mit X11-Unterstützung über das Lucid-Toolkit erstellt, um dem Benutzer die Ausführung von Emacs in einer Fensterumgebung zu ermöglichen.

  4. Das Paket emacs-nw wurde ohne GUI-Unterstützung erstellt. Es eignet sich zur Ausführung im Terminal.

Hinweis:

  • Die Pakete emacs, emacs-gtk+x11, emacs-lucid und emacs-nw packages müssen alle „Requires: emacs-common“ einbinden.

  • Die Pakete emacs, emacs-gtk+x11, emacs-lucid und emacs-nw verfügen alle über ein virtuelles „Provides“: emacs(bin).

Angenommen, Ihr Add-on-Paket funktioniert sowohl in einer Fenster- als auch in einer Konsolen-Emacs-Sitzung, ist die Angabe Requires: emacs falsch, da dadurch eine Abhängigkeit von GTK entsteht, selbst wenn die Konsolenversion von Emacs installiert ist. Verwenden Sie stattdessen für GNU-Emacs-Add-on-Pakete Requires: `emacs(bin).

Wenn das Paket NUR mit der in Emacs integrierten GTK-Unterstützung funktioniert, sollte es die Zeile Requires: emacs enthalten. Dies ist äußerst unüblich.

Warum wir versionierte „Requires“ brauchen

Viele Elisp-Pakete streben Abwärtskompatibilität auf Quellcodeebene an, indem sie prüfen, ob bestimmte Funktionen in der verwendeten Emacs-Version vorhanden sind, wenn das Paket ausgeführt oder bytekompiliert wird. Falls ja, verwenden sie die verfügbaren Funktionen. Falls nein, stellen sie eigene Versionen der fehlenden Funktionen, Makros usw. bereit. Dies wird während der Bytekompilierung in die *.elc-Dateien übernommen, und zwischen den offiziellen Emacs-Veröffentlichungen werden regelmäßig neue Funktionen hinzugefügt.

Nehmen wir an, ich byte-kompiliere ein Paket mit Emacs 29.3 in *.elc. Das Elisp-Paket quux prüft, ob die Funktion foo-bar in der verwendeten Emacs-Version verfügbar ist. Sie ist verfügbar, daher landet die interne, abwärtskompatible Version von foo-bar, die in quux enthalten ist, nicht in *.elc. Angenommen, foo-bar wurde in Emacs 29.3 hinzugefügt und existierte in 29.2 nicht, und wir versuchen, *.elc mit 29.2 auszuführen – dann ist foo-bar nicht verfügbar. Hinweis: Dies würde nicht passieren, wenn nur *.el ausgeliefert würden – *.elc sind die potenzielle und wahrscheinliche Fehlerquelle. Die Anforderung, dass die Emacs-Version >= für die Byte-Kompilierung der *.elc verwendet wird, ist nicht die einzige Lösung (und auch nicht ausreichend für alle Sonderfälle), aber die beste, die uns derzeit zur Verfügung steht.

Das Hauptpaket und seine Teilpakete benötigen entsprechend versionierte Abhängigkeiten (Requires), um sicherzustellen, dass eine hinreichend aktuelle Version von Emacs installiert wird. Byte-kompiliertes Lisp für Emacs ist in der Regel aufwärtskompatibel zu späteren Emacs-Versionen, jedoch häufig nicht zu älteren Versionen.

Ermittlung der erforderlichen Emacs-Version beim Erstellen des Pakets

Es wird empfohlen, versionierte Abhängigkeiten mit Werten größer oder gleich der Emacs-Version abzuleiten, die zum Kompilieren des Pakets verwendet wurde. Das Paket emacs-common enthält /usr/lib/rpm/macros.d/macros.emacs, welches ein %{_emacs_version}-Makro definiert, das die installierte Emacs-Version enthält.

Andere Pakete, die Emacs-Add-ons enthalten (Fall 2)

Es kommt häufig vor, dass Softwarepakete, obwohl sie nicht primär als Emacs-Add-on gedacht sind, Komponenten für Emacs enthalten. Beispielsweise enthält das Programm Gnuplot einige Elisp-Dateien zum Bearbeiten von Gnuplot-Eingabedateien in GNU Emacs und zum Ausführen von Gnuplot aus GNU Emacs heraus. In diesem Fall möchten wir die Emacs-Unterstützung aktivieren, falls Emacs installiert ist. Wir möchten die Installation von Emacs jedoch nicht bei der Installation dieses Pakets erzwingen, da Emacs für die Kernfunktionalität des Pakets nicht erforderlich ist. Um dies zu ermöglichen, wurde das Teilpaket emacs-filesystem erstellt, das das Verzeichnis /usr/share/emacs/site-lisp verwaltet. Ein Paket kann dann das Paket emacs-filesystem über Requires einbinden, um seine Elisp-Dateien zu installieren, ohne Emacs und dessen Abhängigkeiten mit hereinzuziehen.

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