perl: squeeze release, 5.12 transition, etc.

[Niko Tyni]

On Mon, Feb 07, 2011 at 09:20:34PM +0000, Dominic Hargreaves wrote:

(sorry about the slow reply)

> If you'd be happy for me to go over the current bug list and do a bit of
> categorisation/chasing/prodding etc as necessary I'm happy to. This would
> be a good way for me to become familiar with the nature of the perl package
> maintenance task :)

I see you already got started, thanks! All help is certainly welcome.

> > Otherwise, I'll try to set up a rebuild environment again and see where
> > we are with the FTBFS bugs and the like. While the rebuilds themselves
> > don't really require much developer time, I fear I can't be very fast
> > at sorting through the rebuild logs and filing relevant bugs.  I suppose
> > this task could be distributed quite easily if there are volunteers.
> 
> I would be willing to take this on. Do you have any notes from when you
> did this before which might help? Otherwise I'll just have a go from
> scratch.

Yeah. 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.

I've been using the scripts at

 http://svn.debian.org/wsvn/pkg-perl/scripts/perl-5.10-transition/

for determining the necessary binNMUs. I'll try to write up something
about the process on the wiki page you set up (thanks!)

It would be good to have a shared public repository for uploading
the binNMUs. I was earlier using 
 http://people.debian.org/~ntyni/perl/
but the alioth web space for the perl project would probably be better.
I've found reprepro a very good tool for managing the repository.

Oh, and just in case you're already getting started: please consider
using i386 instead of amd64 if possible; the use64bitint changes in 5.12
are only effective on the 32-bit architectures so i386 should give better
test coverage. (I think did a partial rebuild on i386 last year and only
found one or two problems related to use64bitint, though.)

> Presumably most of the work we'd do on 5.12 will be of use in 5.14
> anyway, so we can be responsive to external influences here (demand
> for 5.12 vs timescales for 5.14 vs release time transitions).

Agreed. We need to talk to the release team, but I'd like to have an
updated view of the work needed for 5.12 first.

I don't know yet how intrusive 5.14 will be, but I don't expect any major
problems. Upstream is generally very careful about backward compatibility.

> An alternative to managing patches in git this way would be a more
> traditional quilt-like scheme (I've switched a few of my packages to
> 3.0 (quilt) recently which I find offers a reasonably smooth workflow
> at least for simple packages). Do you have a feel for whether that would
> work well for perl (I assume there are reasons that you didn't go that
> way when you set up the current system)?

The topgit usage in the perl package actually predates 3.0 (quilt).

I dislike having to check in debian/patches and keep it (semi-)manually
updated alongside the actual code changes. Even worse is only managing
debian/patches in the VCS and keeping the upstream code untouched,
which is what the pkg-perl team does.

I think 3.0 (quilt) makes it possible to avoid the latter issue anyway.
The topgit and git-dpm helpers are about avoiding the first one. I
suppose I could live without such a system but it does feel "wrong" to me.

I see gbp-pq in git-buildpackage is yet another option, similar to git-dpm
AFAICS. I haven't tried that yet.

FWIW, a relevant debian-devel thread starts at
 http://lists.debian.org/debian-devel/2010/02/msg00087.html
-- 
Niko