Differences between revisions 86 and 87
Revision 86 as of 2014-01-12 11:46:02
Size: 6447
Comment: add ref to libperl-apireference-perl needing to be updated
Revision 87 as of 2014-01-12 11:46:58
Size: 6413
Comment: ref was already there, moved to be more likely to be spotted
Deletions are marked like this. Additions are marked like this.
Line 102: Line 102:
 * libperl-apireference-perl will need to be updated as it has explicit references to each version of perl (eg: DebianBug:647122)
Line 108: Line 107:
 * libmodule-corelist-perl will need updating to track the data added for the new release.
 * libperl-apireference-perl will need updating to track the data added for the new release.
 * The following packages will need sourceful uploads:
  
* libmodule-corelist-perl will need updating to track the data added for the new release.
   * libperl-apireference-perl will need to be updated as it has explicit references to each version of perl (eg: DebianBug:647122)

Some notes/TODO relating to perl interpreter maintenance.

Work related to Perl 5.18

Rebuilding packages

The main complication is that we need unofficial binNMUs of the perlapi-* and libperl reverse dependencies so that they can be used as build dependencies for rebuilding the rest.

The scripts at http://anonscm.debian.org/gitweb/?p=pkg-perl/scripts.git;a=blob;f=perl-5.10-transition/perlapi.out can be used to determine the necessary binNMUs; the order also matters because the dependencies form a chain.

Example: libdevel-caller-perl is needed by libdevel-lexalias-perl, libpadwalker-perl is needed by libdevel-caller-perl etc.

  • set up an sbuild chroot with Perl 5.12 (note that debconf-english may need to be installed manually in place of debconf-i18n so that build-essential stays installable)
  • convert an up to date perlapi.out into sbuild commands like
    • sbuild -c exp -d unstable --make-binNMU="Rebuild for Perl 5.12" --binNMU=1 libgoo-canvas-perl_0.06-1
  • upload the results into an unofficial repository (reprepro is a good tool; maybe the Alioth web space should be used to push these out to public?)
  • file bugs for any failures
  • once all the necessary binNMUs are uploaded, proceed to test rebuild all the arch:all packages (lib*-perl is a first approximation)
  • note that testing on i386 instead of amd64 would be better, as the use64bitint changes in 5.12 only affect 32-bit architectures -> better test coverage

  • a 32-bit chroot and the schroot Personality option should be good enough on an amd64 host

Other issues

  • BTS:
    • categorizing and triaging bugs
      • I think usertags could help here, we just need a sensible list
    • closing invalid bugs
      • Eugene has done a lot of this already, but I think there are still plenty left
    • forwarding triaged bugs upstream if they're present on unmodified bleadperl
      • we could definitely do better here; I'm personally erring much too often on the side of "I'll write a patch first" and then forgetting about it
      • OTOH upstream has explicitly stated that documentation bugs should come with patches
    • fixing the `real' Debian-specific bugs
      • this is often hard because perl is such a core package in Debian and needs to change conservatively
      • examples: (495394)

  • Debian-specific patches (debian/patches/debian/*)
    • document what they do, why they are needed etc.
      • + possibly create one `divergence bug' per patch in the BTS to track this?
    • ideally, find a way to drop them or integrate them upstream
      • upstream has quite high standards so quick hacks usually don't make it in
      • specific notes:
        • debian/cpan_config_path may be obsolete with 5.14? It looks like upstream CPAN no longer tries to write a CPAN::Config file if it doesn't exist already, but falls back to CPAN::?MyConfig under $HOME.

  • Alioth infrastructure:
    • sending git commits to the PTS
    • mailing list setup, spam filtering, moderation
      • anything still needed?
    • project web pages and other documentation
      • other than maybe a basic jumping off point pointing to the wiki, PTS etc, what sort of things would go here?
  • general peer review
    • getting git commits via mail should help here

git-dpm use

Reverting a patch

git dpm checkout-patched
git log
<search for commit hash of patch to revert> - also note short log message
git rebase -i <commit hash>^
The commit in question should be listed first. Delete it.
git dpm dch

Other

Upstream support policy

http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2011-04/msg00352.html

5.10 (in squeeze) will be desupported by upstream at the release of 5.14. According to my reading of that announcement this will effectively end security support for 5.10 at the same time (since 5.10.0 was released more than three years ago).

Package maintenance policies

  • We only apply patches which have already been applied in bleadperl if at all possible, or at least have been forwarded upstream
    • should this include dual-lived modules?

Bug tagging notes

We should probably define some useful usertags. Some initial thoughts:

  • Things fixed upstream: tag which (major?) version. Suggested name: fixed-upstream-$maj_ver
  • or only on CPAN: fixed-upstream-cpan
  • Divergence bugs (see above) for all Debian-specific patches:
    • probably different sub-categories?

New upstream release checklist

These are some things to consider when uploading (even a point release) new upstream version to unstable)

  • Bump major version trigger? (probably only for incompatible APIs)
  • The following packages will need a binNMU (only for point release updates in ALL archs) as they will be rebuilt during the main ABI transition anyway. The command needs the extra-depends parameter to ensure that the new perl is installed in the buildd chroots (cf. 632467).

    • libpar-packer-perl (551356)

    • libdevel-cover-perl (562214)

    • libclass-xsaccessor-perl (Add dependency on same upstream version of perl to make sure #define PERL_CORE never breaks things.)
    • libcommon-sense-perl needs a BinNMU despite being arch:any internally, but how the resulting pure-perl .pm looks and works depends a lot on the Perl version its build with (722332)

  • The following packages will need sourceful uploads:
    • libmodule-corelist-perl will need updating to track the data added for the new release.
    • libperl-apireference-perl will need to be updated as it has explicit references to each version of perl (eg: 647122)

  • Check other dual-lived modules which have changed in case updates are needed (but that is less likely)
  • Make sure the new version number is added to debian/released-versions

Related pages