From Fedora Project Wiki

< ChrisWeyl

Revision as of 04:26, 8 November 2008 by Cweyl (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Fedora Perl SIG Mission

To assist packagers in bringing Perl-related packages to Fedora Extras and assisting in their continued maintenance by providing timely reviews, acting as secondary package owners and assisting with related security issues.

Perl Components in Fedora

Core Perl

Core perl in Fedora is currently 5.8.8. With 5.10 around the corner (and -RC1 already released), we need to start planning when and how to update perl in devel to 5.10.


  • Bugzilla - Defect Tracking System
  • Bugzilla
  • Some testing on an SELinux-enabled system is still needed (see FE review request)
  • FE review request: #188359
  • Cluster SSH - Cluster Admin Via SSH
  • Alzabo - Data modelling tool (also in CPAN)


  • Catalyst - MVC Web Application Framework (also in CPAN)
  • [1]
  • Bricolage - Content Management System (CPAN: Bundle::Bricolage)
  • Needs work to make it play nice with Apache2/mod_perl2.
  • POE - Portable multitasking and networking framework
  • [2]
  • While POE itself is packaged, there are many, many additional POE-based modules, not all of which are packaged, see, e.g., POE Distributions .
  • Moose - Modern perl5 OOP system


  • Parrot - Parrot Virtual Machine

mailling list thread

  • Pugs - A Perl 6 Implementation written in Haskell

mailing list thread

  • microperl

Perl packages in Fedora

Please edit the wishlist if you want something, or package something off it if you're bored :)

Bugzilla is an excellent place to find information about the various perl packages in or being reviewed for inclusion:

Fedora perl infrastructure

Perl to CPAN Mapping

With most perl modules being in CPAN, preliminary "mapping" table has been created. This table is regenerated on a daily basis, and will be included in the upcoming Perl SIG Infrastructure hosted project .

Problems that need to be addressed

The following topics need to be discussed/improved/corrected. We need to start discussing them in the fedora-perl-list.

  • Improve the RPM perl scripts (requirements and provides detection)
  • at least try to handle use statements a litte better (eg: use base Module; use autouse Module; ...)
  • RPM 4.4.3 perl: handle the ‘v’ in “use v5.6.0″ (#140597)
  • RPM 4.4.3 resurrect a rpm-perl subpackage from perl-RPM2-0.66
  • RPM 4.4.4 complete forking perl-RPM2/* to perl/* module name “RPM”
  • RPM 4.4.5 fix: perldeps and not to emit perl(main) (#177960)
  • Try to have RPM patched in order to create the debuginfo files after the %check section script is executed and not before (right now the files are created after the %install check script is executed). This breaks the signature tests (there are also other problems related to the signature tests in the building environment: network access to import pgg keys, where should they be stored, ...). More information available here and in bug #167252 .
  • How to update core perl modules? Use the site_perl dirs? /usr/local dirs? Problems with man pages

conflicts, version provides clashes (can cause strange problems during package upgrades), .... Already being discussed here: Bug 142837 – Need site-specific man page directory

  • Try to reduce the number of @INC directories.
  • Have a common dir for noarch modules instead of one for each perl version supported.
  • The magic that is perl(:WITH_xxx) needs to be better documented and explained, so packagers -- and reviewers! -- know:
  • What they are and what they mean
  • When to use them
  • When to _not_ use them
  • Common things to check for that would indicate their usage


  • Clarified packaging guidelines - Some of the packaging guidelines have conflicted with some common practises.

For example, BuildRequires: perl was common but forbidden; that has now been changed. One current issue is the prohibition against including header files in the main package; some perl modules include these deep in the module directory hierarchy, and moving them to a separate -devel package is pointless.

  • Notes about "Makefile.PL vs Build.PL" or "ExtUtils::MakeMaker vs Module::Build"


Packagers/Reviewers/People interested in helping

  • JasonTibbitts
  • JoseOliveira (jpo)
  • PaulHowarth
  • StevenPritchard
  • ChrisWeyl
  • GavinHenry
  • ParagNemade