Perl/updates

Tips&tricks for updates of Perl packages.

Updates of Perl core modules

Old style of updates: update whole perl core package. Creating updates of modules in main perl package is complicated, sometimes almost impossible because of change in directories/paths inside of the main package.

Why we need updated modules: e.g. Module::Build is used for build and installation. New packages need the latest version, which makes the process of packaging perl modules slower and painful. This process should help maintainability of core perl package.

Maintainer: The maintainer of (main) perl package should be (co-)maintainer of the new package.

How update core modules e.g. Module::Build

1. create separated module with cpanspec
2. check whether module has Epoch in perl.spec
3. install dual life packages into vendor because of conflicting debuginfos
4. check with rpmdev-vercmp whether version is really higher because of difference in rpm/cpan versions
5. review in bz, cvs, build, update

Be careful with backporting updates into older releases of Fedora. Some older packages could have troubles e.g. with new Module::Build.

Updates of perl modules

For updates has been developed Fedora::App::MaintainerTools

Usage:

maintainertool updatespec perl-Something.spec

What does it do:

• download new source
• change BuildRequirements and Requirements
• write changes into changelog

* Fri Jul 09 2010 Marcela Mašláňová <mmaslano@redhat.com> 3.65-1
- update by Fedora::App::MaintainerTools 0.006
- updating to latest GA CPAN version (3.65)
- added a new br on perl(ExtUtils::MakeMaker) (version 0)
- altered br on perl(HTML::Tagset) (3.03, => 3)
- added a new br on perl(Test::More) (version 0)
- added a new br on perl(XSLoader) (version 0)
- altered req on perl(HTML::Tagset) (3.03 => 3)
- added a new req on perl(XSLoader) (version 0)

But, maintainertool can't handle unusual macros like: Name: perl-%{real_name}. This module wasn't packaged, because it's still under development and BR RPM::VersionSort doesn't have license.

Upgrades of perl interpreter

If you upgrade interpreter to binary compatible version, just add the Provides: perl(:MODULE_COMPAT_major.minor.micro) to set of similar provides.

If you upgrade to binary incompatible but application compatible version, provide the new MODULE_COMPAT symbol and rebuild all perl packages. Rebuilding architecture specific packages should be enough.

If you upgrade to application incompatible version, you need to provide new MODULE_COMPAT symbol, remove all previous MODULE_COMPAT symbols, and rebuild all perl packages (architecture specific to compile/link to new libperl and noarch to get new MODULE_COMPAT Requires into binary packages).

Rebuilding all perl packages consumes a lot of time (1845 spec files in year 2011) and hits a lot of bugs in spec files like missing BuildRequires, cyclic dependencies etc. You can use scripts from perl-Fedora-Rebuild package to rebuild all perl packages in correct (not always correct because of dual-lived modules) order and in parallel manner (to save time). There is a script that lists names of all source packages producing perl binary packages (those that requires MODULE_COMPAT macro) too. Not to burden regular rawhide users and packagers, request dedicated build root in Koji by filling a rel-eng ticket and request merging the build root back to rawhide then.

Be ware you cannot drop old MODULE_COMPAT symbol from perl immediately because minimal build root contains few packages that require Perl at run-time (list Koji group build or see root.log) and could not be installed to prepare build root in Koji. You can drop the provided MODULE_COMPAT symbols after rebuilding those perl dependencies (currently: git, perl-Error, perl-PathTools, perl-Scalar-List-Utils, perl-threads-shared, perl-threads, perl).