WARNING
This page badly needs an update. It's best not to rely on any of this information unless you're a src:perl uploader (and not even then).
Some notes/TODO relating to perl interpreter maintenance.
- 5.32 is in unstable and stable as of August 2021
5.34 is in experimental as of August 2021, known regressions at https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=perl-5.34-transition;users=debian-perl@lists.debian.org
Rebuilding packages for a major version transition
This is done using a debomatic setup now, mostly managed via https://salsa.debian.org/perl-team/perl.debian.net
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 https://salsa.debian.org/perl-team/scripts/tree/master/perl-transitions are used to determine the necessary binNMUs; the order also matters because the dependencies form a chain.
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)
- categorizing and triaging bugs
- 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.
- document what they do, why they are needed etc.
- 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
General patch management: http://anonscm.debian.org/gitweb/?p=perl/perl.git;a=blob;f=debian/README.source
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 new upstream version to unstable
All versions
- Bump major version trigger? (probably only for incompatible APIs, almost never in a point release)
- Make sure the new version number is added to debian/released-versions (only) when uploading to unstable
- Make sure that perl-base provides the appropriate perlapi-* virtual packages (ie 5.28.1 should still provide perlapi-5.28.0 if that release ever made it to unstable).
If https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=974004 is still open, consider sending a courtesy note about the upcoming upload
Point releases only
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). A summary of why these dependencies are needed is in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981232#32.
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 it's built with (722332)
libdevel-mat-dumper-perl (encodes perl version in binary, 981408)
- Example:
$ wb nmu libpar-packer-perl libdevel-cover-perl libclass-xsaccessor-perl libcommon-sense-perl libdevel-mat-dumper-perl . ANY . -m "Rebuild against perlapi-5.26.2." --extra-depends 'perl-base (>= 5.26.2)'
- Make sure that the previous version number released to unstable is added to debian/released-versions
New major upstream versions only (when uploading to unstable)
NOTE: this list is not comprehensive, there is lots more detail involved in a major version update
- Change the default branch in salsa to the new one (eg debian-5.30)
- Change the branch that the tagpending webhook listens for in salsa (as above)
- Ensure that the current cross build configs are included, particularly a release is targeted at an upcoming release. See debian/cross/README.
For a stable update
In May 2016 an update was prepared for stable including a mass-import of relevant patches from an upstream point release. This worked well, but did result in one regression (826563). In future we should consider the changes and the likelihood of breaking things, and run regression tests (for example, use the perl.debian.net infrastructure to rebuild (in stretch/stretch-proposed-updates) all packages depending on perl. This takes a day or two).