Perl Modules Conundrum

Scott Kitterman scott at
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.

Scott K

More information about the ubuntu-devel mailing list