Pautas del Empaquetado de Perl

Nombrado del paquete del módulo

Consulte Directrices de empaquetado: Nomenclatura: Módulos Perl.

Etiqueta de Licencia

Consulte Licensing guidelines specific to Perl.

Propiedad del Directorio

Como se especifica en las Directrices de Empaquetado generales, se espera que los paquetes Perl compartan la propiedad de ciertos directorios.

En general, un paquete Perl noarch debe tener:

# Para paquetes noarch: vendorlib
%{perl_vendorlib}/*

…​y un paquete de Perl con el arch específico debe ser proporcionado:

# Para los paquetes específicos de la arquitectura: vendorarch
%{perl_vendorarch}/*
%exclude %dir %{perl_vendorarch}/auto/

Compilar Dependencias

Como declarado en Directrices de Empequetado: Dependencias en Tiempo de Compilación (BuildRequires), un paquete debe tener explícitamente sus dependencias de compilación (utilizando BuildRequires:) fuera del conjunto mínimo requerido para RPM para crear paquetes. Esto incluye cualquier dependencia en Perl. Mientras Perl pueda haber estado dentro de la raíz de compilación (buildroot) a la vez, esto actualmente no es el caso.

A continuación está un listado de dependencias de construcción relacionados con Perl que puede necesitar.

  • perl-generators – Automáticamente genera Requires y Provides en tiempo de ejecución para archivos de Perl instalados. Siempre que instalas un guion Perl o un módulo de Perl, debes incluir una dependencia de creación en este paquete.

  • perl-interpreter – El intérprete de Perl debe estar enumerado como una dependencia de creación si esto es invocado dentro de cualquier manera, o bien explícitamente por medio de perl o %__perl, o como parte de su sistema de creación del paquete.

  • perl-devel - Proporciona la cabecera de los archivos de Perl. Si se crea código basado en especificaciones de arquitectura los cuales se enlazan a bibliotecas libperl.so (p.ej., un módulo XS de Perl), debe incluir BuildRequires: perl-devel.

Si se requiere un módulo Perl específico en tiempo de creación, utilice la sintaxis de perl(MÓDULO) como se documentó antes. Esto aplica a módulos tales como core también, ya que puede trasladar dentro y fuera el paquete de Perl a lo largo del tiempo.

Si se necesita limitar su paquete de Perl a una versión concreta, utilice la dependencia perl(:VERSION) con la restricción de la versión deseada (p. ej. perl(:VERSION) >= 5.22). No utiliza una comparación contra la versión del paquete de perl porque ello incluye un número de época, el cual hace comparaciones delicadas de la versión.

Requerir y Proporcionar Perl

Los paquetes de Perl utilizan el nombrado virtual perl(Foo) para indicar un módulo de Perl dado. Los paquetes utilizarían esta metodología, y no requiere el nombre del paquete directamente. Por ejemplo, un paquete que requiere el módulo Readonly de Perl no requeriría explícitamente perl‐Readonly, sino en su lugar perl(Readonly), el cual el paquete perl‐Readonly lo proporciona.

Está recomendado incluir dependencias explícitas para módulos core, porque pueden mover entre sub‐paquetes o desaparecer desde el Perl core.

Requisitos MODULE_COMPAT_ versionado o perl‐libs

Los paquetes con módulos de Perl instalados en %{perl_vendorarch}, %{perl_vendorlib}, %{perl_privlib} o %{perl_archlib} obtendrán automáticamente la dependencia en perl-libs para módulos puros de Perl o una dependencia en perl(:MODULE_COMPAT_<perl_version>) para bibliotecas con código compilado. La dependencia está manejada por perl-generators.

Los paquetes que requieren el intérprete de Perl o libperl.so pero no instala módulos para los directorios anteriormente mencionados o enlaces explícitamente para libperl.so.<perl_version> necesitan de manejar la dependencia manualmente.

Filtrado de Requisitos y Provisiones

El generador dependiente de RPM puede obtener a través de dependencias adicionales y a menudo podrá pensar paquetes que proporcionen funcionalidad contraria a la realidad. Para reparar esto, las necesidades del generador de la dependencia para ser anulado tal que las dependencias adicionales pueden ser filtradas fuera. Consulte las Directrices de Empaquetado: Filtro Automático de Provisión y Requisitos - Perl para información.

Manual de Requerir y Proporcionar

Bajo algunas circunstancias, la dependencia automática del generador de los RPM puede perder dependencias que estarían añadidas. Usualmente esto es un resultado de utilizar constructores del lenguaje que la dependencia no esperada. Un ejemplo de este es en el paquete perl-Class-Accessor-Chained, donde el siguiendo puede ser encontrado:

use base 'Class::Accessor::Fast';
...
use base 'Class::Accessor';

Una señal reveladora de este constructor particular es que el paquete contiene una dependencia en perl(base), pero esto no es la situación única en cuyas dependencias pueden ser perdidas. Este paquete necesitaba dependencias adicionales como siguen:

Requiere: perl(Class::Accessor), perl(Class::Accessor::Fast)

En general, es una idea buena mirar en la documentación del paquete en desarrollo para detalles de otras dependencias.

Otro ejemplo similar de requisitos ausentes puede ser visto en perl-Spreadsheet-WriteExcel:

package Spreadsheet::WriteExcel::Utility;
...
use autouse 'Date::Calc'  => qw(Delta_DHMS Decode_Date_EU Decode_Date_US);
use autouse 'Date::Manip' => qw(ParseDate Date_Init);

Similarmente, lo posible de perder Provides:, como era el caso en Bug #167797 , donde el paquete perl-DBD-Pg falló para Provide: perl(DBD::Pg) debido al siguiente constructor en DBD::Pg con la versión 1.43:

{ package DBD::Pg;

La manera habitual de escribir esto, y qué está esperado por RPM, es:

{
package DBD::Pg;

Así que es sensato examinar el Provides: de sus paquetes para comprobar que esos son correctos y completos. Si algo falta, puede ser reparado o bien utilizando apuntes de Provides: manual, o bien a través de parches de la fuente para utilizar un formato que RPM puede interpretar correctamente.

Etiqueta URL

Para paquetes basados en CPAN la etiqueta de URL utilizaría un URL metacpan.org no versionado. P. ej., si uno estaba empaquetando el módulo Net::XMPP, la URL sería:

URL: https://metacpan.org/release/Net-XMPP

Testeo y Suite de Prueba

Los paquetes Perl típicamente tienen una suite de prueba grande, sana. Es directiva para ejecutar tanto como la suite de prueba tanto como sea posible, sujeto para las limitaciones técnicas del sistema de creación. Esto significa, al menos:

  • Todos los módulos requeridos para las pruebas serían alistados como un BuildRequires

  • Cualesquiera pruebas "opcionales" estarían habilitadas

  • Cualquiera de los módulos para las pruebas pero aún no en Fedora que podrían ser incluidas en Fedora además seŕian enviadas para revisar

Cuando no probar

Hay un pareja de salvedades aquí:

  • Las pruebas opcionales no necesitan estar habilitadas si causarían dependencias de creación circulares

  • Prueba cuales requieren acceso por red o pantalla estaría inhabilitada para el sistema de creación, pero con un método proporcionado para creaciones locales

  • Las pruebas las cuáles no testean funcionalidad del paquete todavía sería invocada, pero su exclusión no es considerada un bloqueador (p. ej. Test::Pod::Coverage, Test::Kwalitee y similares)

  • Autor, "candidato de lanzamiento", o pruebas de humo no necesitan estar habilitadas p. ej. pruebas utilizando Perl::Critic.

Adicionalmente, para paquetes "meta" que proporciona una interfaz común a un número de módulos similares, no es necesario empaquetar todos los módulos que soporta el paquete siempre y cuando al menos un módulo existe para dejar el meta paquete que proporcione funcionalidad. Para caso, el paquete perl-JSON-Any (JSON::Anyr) proporciona un interfaz común a JSON, JSON::XS, JSON::PC, JSON::Syck y JSON::DWIM; JSON::PC y JSON::DWIM no están actualmente en Fedora y no necesitan empaquetarse como, p. ej., JSON::XS para habilitar JSON::Any.

Condicionalmente habilitar/inhabilitar pruebas

Uno manera común para inutilizar una prueba para simular pero habilitarlo localmente se hace para utilizar una prueba de macro _with_foo, p. ej.,

%check
%{!?_with_network_tests: rm t/roster.t }
./Build test

Con esta construcción, una prueba ofendida será eliminada y no ejecutada, a no ser que --with network_tests está aprobada para rpmbuild o %_with_network_tests` está definida a algún lugar, p. ej. en un usuario $HOME/.rpmmacros+. Esta aproximación preserva la prueba suite para complexiones locales mientras obrando dentro de las limitaciones técnicas del sistema de complexión.

Makefile.PL vs Build.PL

Los módulos Perl típicamente utilizan uno de dos complexión diferente sistemas:

  • ExtUtils::MakeMaker

  • Module::Build

Las dos diferentes estilos son reconocibles fácilmente: ExtUtils::MakeMaker emplea el archivo Makefile.PL de generación, y es la aproximación "clásica"; Module::Build es una aproximación más nueva , con mantenimiento para cosas de MakeMaker que no pueden hacerse. Mientras la elección definitiva de cual sistema a emplear claramente está en las manos en desarrollo, si Build.PL está presente en una distribución el empaquetador emplearía ese marco de generación a no ser que haya una razón buena para hacer en otra parte.

Consulte además PackagingTips/Perl#Makefile.PL_vs_Build.PL .

Archivos .h en paquetes del módulo

No es poco común para paquetes de módulo binario para incluir archivos .h, consulte p. ej. perl-DBI, perl-Glib, perl-Gtk2. Para una variedad de razones estos no tendrían que separar en un paquete -devel.

Actualizaciones de paquetes

Sumario de herramientas utilizadas para las actualizaciones y los comentarios útiles pueden encontrarse aquí en Perl/updates.

Consejos útiles

Algunos módulos intentan atraer módulos desde CPAN. En vez de parchear el makefile, fácilmente puedes añadir PERL5_CPANPLUS_IS_RUNNING=1 para evitar CPAN enteramente.

Perl SIG

La gente alrededor de Perl, quienes estén empaquetando, manteniendo y revisando paquetes. Si estás interesado en Perl, únase en la lista de correo, donde se discuten las últimas incidencias.

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