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:
> The following packages have unmet dependencies:
> libcompress-raw-zlib-perl: Depends: perlapi-5.8.8 which is a virtual
> 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.
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.
Niko Tyni email@example.com