Re: perlapi-5.8* and the perl 5.10 transition
On Fri, Jan 18, 2008 at 02:12:18PM +0200, Damyan Ivanov wrote:
> I've tried to rebuild all pkg-perl packages with perl 5.10 from
> experimental and I have to say, the situation is not pink :(
> The following packages are BROKEN:
> libcompress-raw-zlib-perl
> The following packages have unmet dependencies:
> libcompress-raw-zlib-perl: Depends: perlapi-5.8.8 which is a virtual
> package.
> The following packages will be DOWNGRADED:
> perl perl-base perl-modules
>
> This downgrade will not be possible when 5.10 is in unstable. The fix,
> however is not trivial at all. It is to build the packages depending on
> perlapi-5.8.8 with perl5.10, which IMHO is best done with binNMUs. Some
> of the binNMUs will fail (for the same reason build-deps depending on
> perlapi-5.8.8), but several runs have to clear the pile.
>
> If anyone can provide a "staircase" approach for this, i.e. a list of
> package to binNMU first (arch-dep, with no build-depends (including
> build-depends dependencies) depending on perlapi-5.8.8), then another
> list which includes packages build-depending (incl. indirectly) on
> packages from the first list, etc, that would be great.
I had a go at this and wrote a small program called 'find-rebuild-order'
that takes a list of uninstallable packages as input and outputs the
order they need to be rebuilt. It also checks for recursive dependencies
of essential and build-essential packages, as those need manual attention.
The program can be found in the pkg-perl SVN repository at
/scripts/perl-5.10-transition/, although it's not pkg-perl specific.
It's written in Perl (of course :) and uses the local apt cache with
the AptPkg::* modules from libapt-pkg-perl.
http://svn.debian.org/wsvn/pkg-perl/scripts/perl-5.10-transition/
I investigated all the 250 modules in the archive that need perlapi-5.8*.
The program is slow and a bit stupid, but I did manage to get a list out,
see 'perlapi.out' in the above directory. If anybody wants to improve
this, please go ahead. I even wrote some pod documentation :)
There may be a bootstrapping problem:
login is an Essential:yes package, which depends on
libpam-modules -> libpam0g -> debconf -> debconf-i18n
while debconf-i18n depends on
(libtext-iconv-perl, liblocale-gettext-perl, libtext-charwidth-perl)
which are all XS modules and need to be recompiled.
This may not be a problem since debconf actually depends on
(debconf-i18n | debconf-english), and debconf-english doesn't need
any XS modules. However, I'm not sure if the buildds will do the right
thing when they see perl 5.10 in unstable. My simple-minded tries with
installing 5.10 from experimental with apt-get lead to removing debconf
and its reverse dependencies instead...
Another problem is libxml-parser-perl, which build-depends on
libxml-encoding-perl, which depends on libxml-parser-perl. So
libxml-parser-perl can't be rebuilt when it's uninstallable.
I found no other obvious problems. Apparently the rest of the packages
will take 5 rounds of binNMUs; the longest build-dependency chain is
for libgnome2-print-perl, eg. via
libgnome2-print-perl build-depends on libgnome2-perl
libgnome2-perl build-depends on libgnome2-canvas-perl
libgnome2-canvas-perl build-depends on libgtk2-perl
libgtk2-perl build-depends on libcairo-perl
and the number of packages for each round is
NOTE: starting round 1: 247 uninstallable packages left
NOTE: starting round 2: 67 uninstallable packages left
NOTE: starting round 3: 32 uninstallable packages left
NOTE: starting round 4: 12 uninstallable packages left
NOTE: starting round 5: 10 uninstallable packages left
NOTE: starting round 6: 9 uninstallable packages left
NOTE: circular dependencies found, quitting with 9 uninstallable packages left
NOTE: all done!
The 9 packages left are due to the libxml-parser-perl problem:
libxml-parser-perl circular dependency: needed by libgdk-pixbuf-perl
libgladexml-perl libgnome-perl libgtk-imlib-perl libgtk-perl
libgtkglarea-perl libgtkxmhtml-perl libnet-dbus-perl libxml-parser-perl
> Some of these packages will also FTBFS due to the rmdir bug so that
> should be cleared first.
Would it make sense to split the 5.10 transition into two by reverting the
fix for the 'empty directory bug' in Extutils::MakeMaker temporarily? This
way the binNMUs for the perlapi-5.8 problem could be done first without
having to worry about the 'rmdir bug', and enabling the fix again
afterwards would only lead to build failures, not uninstallable packages.
Cheers,
--
Niko Tyni ntyni@debian.org
Reply to: