Empaquetado de adjuntos para GNU Emacs

Propósito

El propósito de este documento es promover las buenas prácticas en el empaquetado de complementos para GNU Emacs y fomentar el envío de más paquetes de complementos de Emacs a la colección de paquetes, proporcionando plantillas de archivos spec fáciles de usar.

Notas importantes en estas Directrices

Las pautas en las siguientes secciones hacen un uso extensivo de las macros definidas en /usr/lib/rpm/macros.d/macros.emacs lo cal es instalado con el paquete emacs-common.

Hay dos casos distintos en los que es necesario tener en cuenta estas directrices:

  1. Este caso se refiere a la situación en la que el propósito principal de un paquete es proporcionar funcionalidad adicional para Emacs, y dicho paquete no cumple ninguna función sin la presencia de Emacs. Un ejemplo de este caso es el lector de correo de VM, tal como se incluye en emacs-vm. En adelante, lo denominaremos Caso I.

  2. Este caso se refiere a la situación en la que la funcionalidad principal de un paquete no requiere Emacs, pero el paquete también incluye archivos Elisp auxiliares para proporcionar soporte en Emacs. En adelante, lo denominaremos Caso II.

Nombre de paquetes y organización de subpaquetes

Caso I

Cuando un paquete es principalmente un complemento para Emacs, el paquete principal debería invocarse emacs-foo.

Caso II

Donde la funcionalidad principal de un paquete no requiere Emacs, pero el paquete también incluye algunos archivos Elisp auxiliares para proporcionar asistencia para el paquete en Emacs, estos seríen incluidos dentro del paquete principal el cual necesitará un Require en el paquete emacs-filesystem. Más detalle a continuación.

Contenido del paquete

Caso I

Los archivos específicos para GNU Emacs estarían colocados en el paquete principal, emacs-foo. Esto contendría la fuente de elisp, elisp compilado y otros archivos necesarios para utilizar el paquete o sub‐paquete con GNU Emacs.

Caso II

La fuente elisp compilada y los archivos de la fuente elisp serían empaquetada como parte del paquete principal, y no desglosada en paquetes separados.

Localizaciones del archivo

Las localizaciones del archivo para los (sub-)paquetes del complemento de GNU Emacs:

  • Todo los elisp y los archivos relacionados para el paquete serían instalados dentro del directorio %{_emacs_sitelispdir}/foo.

  • Si el paquete requiere un archivo de arranque este sería llamado foo-init.el y estaría situado en %{_emacs_sitestartdir}.

Requisitos de Paquete

Caso I

Los Requisitos del Paquete para los (sub-)paquetes adjuntos de GNU Emacs:

  • Donde sea relevante emacs-foo debe tener Requires: emacs-common-tal= %{version}-%{release}

  • emacs-foo debe tener Requires: emacs(bin)%{?_emacs_version: >= %{_emacs_version}}

Caso II

Si el paquete tiene archivos auxiliares para utilizar con GNU Emacs, el paquete debe tener Requires: emacs-filesystem >= %{_emacs_version}

Paquete BuildRequires

Paquete BuildRequires para paquetes adjuntos de GNU Emacs:

  • En general sería suficiente tener BuildRequires: emacs-nw

Compilación manual de byte

Normalmente, la compilación de paquetes Elisp se realiza mediante un archivo make incluido en el paquete, pero en ocasiones puede ser necesario añadir comandos a la sección %build del archivo de especificaciones para compilar archivos. En ese caso, utilice %{_emacs_bytecompile} file.el

Es un requisito que todos los archivos Elisp estén compilados y empaquetados en bytes, a menos que exista una buena razón para no hacerlo, en cuyo caso esto debe documentarse con un comentario en el archivo de especificaciones.

Uso de BuildArch: noarch

Si un paquete adjunto requiere solo compilación de byte de elisp entonces BuildArch: noarch sería utilizado. Esto es altamente improbable para incluso aplicar a Caso II.

Ejemplo específico de plantillas de archivo

Plantilla para un paquete adjunto para GNU Emacs (Caso I)

Esta es una plantilla para un paquete de GNU Emacs. El paquete principal se llama emacs-foo y contiene todos los archivos necesarios para ejecutar el paquete foo con GNU Emacs. Esto incluye los archivos compilados y los archivos origen de elisp.

%global pkg foo
%global pkgname Foo

Nombre:           emacs-%{pkg}
Versión:
Liberación:        %autorelease
Resumen:

Grupo:
Licencia:
URL:
Origen0:

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

%description
%{pkgname} es un paquete adjunto para GNU Emacs. Hace cosas maravillosas…


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

%build


%install


%post


%preun


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


%changelog
%autochangelog

Plantilla para un paquete el cual contenga archivos auxiliares de GNU Emacs (Caso II)

Esto es un esqueleto de un paquete el cual además incluye archivos de mantenimiento para GNU Emacs

Nombre:           foo
Versión:
Lanzamiento:        %autorelease
Sumario:

Grupo:
Licencia:
URL:
Origen0:

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

%description
Foo es un paquete el cual contiene archivos de soporte Emacs auxiliares.


%prep
%autosetup

%build


%install


%post


%preun


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

%changelog
%autochangelog

Principios detrás de las directrices

Lugar de los archivos instalados

Los archivos del paquete complementario foo deben colocarse en %{_emacs_sitelispdir}/foo lo cual evalúa a /usr/share/emacs/site-lisp/foo.

Usualmente un paquete de complemento requerirá un archivo startup, y esto sería invocado foo-init.el y sería situado en %{_emacs_sitestartdir} lo cuál evalúa a /usr/acción/emacs/sitio-lisp/sitio-inicio.d/.

Empaquetado de archivos fuentes de elisp

Típicamente, un paquete de complemento de Emacs estará compilado desde los archivos fuente elisp. El elisp resultante compilado de archivos entonces serán incluidos en el paquete pertinentes emacs-foo. Es importante a también incluir el paquete fuente de elisp para varias razones. Por ejemplo cuando depure un problema con un paquete Emacs, el depurador Elisp puede encontrar del código pertinente o definición del símbolo en el archivo lisp fuente si está presente. También, a veces es útil ir a una descripción variable de cadena del sistema de ayuda en Emacs.

BuildArch para complemento de paquetes de Emacs

Tendrías que poner BuildArch: noarch para los complementos del paquetes solo compilan archivos elisp durante la construcción.

Si el proceso de construcción del paquete además compila programas en otros lenguajes, puede necesitar no poner BuildArch.

Requieren para GNU Emacs

Paquetes adjuntados tendrían apuntes Requieres apropiados para el la versión de Emacs destinados. GNU Emacs está disponible en múltiples paquetes – algunos detalles de estos paquetes a continuación.

  1. El paquete emacs es compilado con asistencia GTK pura para conceder al usuario ejecutar Emacs en un entorno con ventana.

  2. El paquete emacs-gtk+x11 está compilado con asistencia X11 a través del toolkit de GTK para conceder al usuario ejecutar Emacs dentro de un entorno con ventana.

  3. El paquete emacs-lucid es compilado con asistencia X11 a través del toolkit Lucid para conceder al usuario ejecutar Emacs en un entorno con ventana.

  4. El paquete emacs-nw es compilado sin asistencia de IGU. Es apropiado para ejecutar en un terminal.

Nota:

  • Todos los paquetes emacs, emacs-gtk+x11, emacs-lucid, y emacs-nw tienen Requisitos: emacs-common.

  • Todos los paquetes emacs, emacs-gtk+x11, emacs-lucid, y emacs-nw tienen un Provides: emacs(bin) virtual.

Asumiendo vuestro complemento el paquete funcionará en ambos un windowed y una consola Emacs sesión, es incorrecto tener Requires: emacs como eso atraería una dependencia en GTK incluso si la variante de consola Emacs está instalada. Bastante tendrías que utilizar Requires: emacs(bin) para complemento GNU Emacs paquetes.

Si el paquete SOLO funciona con mantenimiento GTK compilado en Emacs, entonces el paquete tendía Requires: emacs. Esto es muy poco común.

Por qué necesitamos Requires con versiones

Muchos paquetes elisp buscan la compatibilidad con versiones anteriores del código fuente comprobando si existen ciertas características en el Emacs en uso durante la ejecución o la compilación. En caso afirmativo, utilizan lo disponible. En caso negativo, proporcionan sus propias versiones de funciones, macros, etc., que faltan. Esto se propaga a *.elc durante la compilación, y se añaden bastantes funciones entre versiones originales de Emacs.

Digamos que compilación por byte de un paquete en *.elc con Emacs 29.3. El paquete Elisp quux comprueba si la función foo-bar está disponible en el Emacs que se usa para compilarlo. Sí, lo está, por lo que la versión interna de retrocompatibilidad de foo-bar incluida en quux no termina en *.elc. Ahora, supongamos que foo-bar se añadió en Emacs 29.3 y no existía en 29.2, y estamos intentando ejecutar *.elc con 29.2 → ¡zas!, foo-bar no está disponible. Nota: esto no ocurriría si solo se hubiera incluido *.el; *.elc es el problema potencial y probable. Exigir una versión >= del Emacs utilizado para compilar en bytes el *.elc no es la única solución (ni suficiente para todos los casos especiales), pero es la mejor que tenemos disponible actualmente.

El paquete principal y los subpaquetes deberán tener la versión Requires correctamente versionada para garantizar que se instale una versión reciente de Emacs. El paquete Lisp compilado por bytes de Emacs suele ser compatible con versiones posteriores de Emacs, pero con frecuencia no es compatible con versiones anteriores.

Determinación de la versión de Emacs Required en tiempo de compilación del paquete

Está recomendado para derivar dependencias mayores-que-o-igual-que valuadas desde la versión de Emacs utilizadas para compilar-byte el paquete en tiempo de creación del paquete. El paquete emacs-common incluye /usr/lib/rpm/macros.d/macros.emacs lo cual define una macro %{_emacs_versión} que contenga la versión de Emacs instalado.

Otros paquetes conteniendo adjuntos Emacs en adjuntos (Caso II)

Es frecuente que un paquete de software, aunque no sea principalmente un complemento de Emacs, contenga componentes para Emacs. Por ejemplo, el programa Gnuplot contiene archivos elisp para editar archivos de entrada de Gnuplot en GNU Emacs y ejecutar Gnuplot desde GNU Emacs. En este caso, queremos habilitar la compatibilidad con Emacs si Emacs está instalado, pero no queremos obligar a su instalación al instalar este paquete, ya que Emacs no es necesario para proporcionar la funcionalidad principal del paquete. Para ello, se creó el subpaquete emacs-filesystem, que contiene el directorio /usr/share/emacs/site-lisp. Un paquete puede entonces requerir el paquete emacs-filesystem para instalar sus archivos Elisp sin tener que instalar Emacs ni su cadena de dependencias.

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