Perl Modules Conundrum
scott at kitterman.com
Mon Jan 7 16:41:50 GMT 2008
Currently there are Perl modules (at least libfile-temp-perl and
libtest-harness-perl) that are provided by the perl-modules package in Perl
and also packaged separately in a later version. It is currently impossible
to build against these separate packages on the buildds.
What happens is that sbuild checks to see if it has such a module installed,
determines that it does, because the module is provided by perl-modules.
Later the build will fail due to dependency problems because the version is
insufficient. An exemplary build log can be found here:
FYI, that package built fine in my pbuilder before I uploaded it, so this is
one of those cases where the difference between pbuilder and sbuild is
This problem has been reported for some time:
The challenge is that provides are versioned, so there's no way for sbuild to
know with it's current design that it should look further. I suspect it's
unrealistic to except a near-term Launchpad/sbuild fix for this.
Due to this problem, libmail-box-perl last successfully built in Edgy.
I haven't done an exhaustive survey of FTBFS due to this problem, but it will
clearly be increasing over time.
My proposed solution to this problem is to rip libfile-temp-perl and
libtest-harness-perl out of perl-modules, promote the separate packages to
Main, and then add them as dependencies of perl-modules to that they could
still be relied on to be present.
This approach would allow building against the newer modules and allow the
newer modules to be upgraded without having to upload Perl every time one of
them changes while still ensuring the modules will be installed for packages
that haven't declared an explicit dependency on them.
Please consider this the "Hold any necessary discussion on ubuntu-devel" part
of the MIR process for libfile-temp-perl and libtest-harness-perl.
More information about the ubuntu-devel