Perl 5.12

[Niko Tyni]

On Fri, Mar 12, 2010 at 08:00:13AM +0200, Damyan Ivanov wrote:
> -=| Niko Tyni, Wed, Mar 10, 2010 at 11:39:13PM +0200 |=-
> > Help with perl maintenance would naturally be very welcome. Eugene 
> > has helped out a lot, and we'd love to have more active 
> > comaintainers.
> 
> What does the process of integrating a new upstream release looks like 
> with topgit? Right now perl's README.source documents only how patches 
> are maintained (which is indeed very useful).

(dropping the debian-perl list, Cc'ing Damyan and Dominic)

The new upstream release is brought in with git import-orig or the
like as usual.

Doing a 'tg update' on master doesn't seem to work because it tries to 
merge the upstream changes to the fully patched Debian version instead
of doing it for each dependency branch first and then merging the result.

I've done some experiments with 5.11.5 and it seems that making a new
temporary TopGit branch based on upstream, updating the topic branches
against that and then merging the result into master gives the desired
results.  Something like:

 git import-orig --no-merge --pristine-tar ../perl-5.11.5.tar.bz2
 tg create merge-5.11.5 upstream
 git config --add merge.renameLimit 20000
 echo 'Temporary branch for merging 5.11.5' > .topmsg && git commit -a -m "$(cat .topmsg)"
  # piping from 'tg info master' to 'tg depend add' would be cleaner...
 git cat-file blob master:.topdeps > .topdeps 
 git commit -m 'Prepare for upgrading all the dependency branches of the master branch' .topdeps
 tg update # recurses to the dependency branches
  # [resolve conflicts manually where needed]
 git checkout refs/top-bases/master
  # merge the result into the master TopGit base 
  # the actual branch will follow with 'tg update'
 git merge merge-5.11.5
  # the base is not a real branch but more like a tag, so it needs an update now
 git update-ref refs/top-bases/master HEAD
 git checkout master
 tg update
 tg delete merge-5.11.5

The only non-trivial conflicts I ran into were on 'debian/mod_paths'
so things don't look too bad.

The process could certainly be easier. Not sure if TopGit could be taught
to do this itself when needed.

I think documenting this is out of scope for README.source; the `patch
handling with topgit' is borderline, and this belongs somewhere on
perl.alioth.debian.org or wiki.debian.org instead IMO.

As 5.12.0 RC0 is due any day now, I'm inclined to skip pushing the
above to a public git repository and rather redo the process with the
RC0 tarball.  Let me know if you want something to play with sooner
and I'll see what I can do.

If somebody wants to help, porting the debian/mod_paths branch/patch to
the current upstream code would go a long way. Upstream has reorganized
@INC and I believe the result is closer to ours, so the patch may well
get shorter now.

One open issue is what we're going to do with deprecate.pm.
I'll raise this on debian-perl, but see `Module deprecations' in
pod/perl5120delta.pod for the background.

I already found some offline time and updated the Conflicts versions in
debian/control. I'm starting to think that we could use a tool based on
Module::CoreList to do it automatically. That would eliminate any typos
as the process is very tedious and error prone. There are quite a few
exceptions with the naming (libansicolor-perl etc.) and the versions
(mainly unexpected epochs) that complicate things a bit.

We could also use an automatic tool to check that perl-base keeps
being self contained, to avoid bugs like #479202 and #549170 this time.
Possibly the tool should even be integrated in the build process so we
wouldn't have to remember running it manually.
-- 
Niko