Perl/updates

From FedoraProject

< Perl(Difference between revisions)
Jump to: navigation, search
(Updates - tips&tricks)
(Link to debuginfo conflict)
 
(10 intermediate revisions by 2 users not shown)
Line 1: Line 1:
This is Draft with tips&tricks, which should help with updates.
+
__TOC__
 +
 
 +
'''Tips&tricks''' for updates of Perl packages.
  
 
= Updates of Perl core modules =
 
= Updates of Perl core modules =
  
Now: update whole perl core package. Creating updates of modules in main perl package is complicated, sometimes almost impossible
+
'''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.  
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
+
'''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.  
+
makes the process of packaging perl modules slower and painful. This process should help maintainability of core perl package.
  
How update core modules e.g. Module::Build
+
'''Maintainer''': The maintainer of (main) perl package should be (co-)maintainer of the new package.
 +
 
 +
'''How update core modules''' e.g. Module::Build
 
# create separated module with cpanspec
 
# create separated module with cpanspec
 
# check whether module has Epoch in perl.spec
 
# check whether module has Epoch in perl.spec
# add Obsoletes: perl(Module::Build) < version-of-perl-Module-Build-in-perl.spec Without this won't be package updated because every core module requires perl-N-V-R.
+
# install dual life packages into vendor because of [http://lists.fedoraproject.org/pipermail/perl-devel/2011-August/040646.html conflicting debuginfos]
 
# check with rpmdev-vercmp whether version is really higher because of difference in rpm/cpan versions
 
# check with rpmdev-vercmp whether version is really higher because of difference in rpm/cpan versions
 
# review in bz, cvs, build, update
 
# review in bz, cvs, build, update
Be carefull with update into older releases of Fedora, because some older packages could have troubles e.g. with new build module.
+
Be careful with backporting updates into older releases of Fedora. Some older packages could have troubles e.g. with new Module::Build.
For updates has been developed [http://search.cpan.org/dist/Fedora-App-MaintainerTools/ Fedora::App::MaintainerTools]
+
  
 
= Updates of perl modules =
 
= Updates of perl modules =
 +
 +
For updates has been developed [http://search.cpan.org/dist/Fedora-App-MaintainerTools/ Fedora::App::MaintainerTools]
  
 
Usage:
 
Usage:
Line 25: Line 29:
 
</pre>
 
</pre>
  
This should help with changes in (Build)Requirements, provides and many more... This module is still under development and at the moment isn't packaged into Fedora.
+
What does it do:
 +
* download new source
 +
* change BuildRequirements and Requirements
 +
* write changes into changelog
 +
<pre>
 +
* 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)
 +
</pre>
 +
 
 +
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).
 +
 
 +
[[Category: Perl]]

Latest revision as of 13:51, 16 August 2011

Contents


Tips&tricks for updates of Perl packages.

[edit] 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.

[edit] 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.

[edit] 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).