Perl Modules Conundrum

[Michael D. Stemle, Jr.]

I'd second pulling these modules out of perl-modules.  I would think
that the only modules that should be in perl-modules would be the ones
that normally ship with Perl itself.  For folks who actually write Perl
regularly--such as myself--being able to know and control exactly which
modules (at which version) are installed is very important, just like
with any other library.

We package C libraries separately, perhaps we should consider packaging
Perl and Python and other libraries separately.  Sure it makes things a
little more complicated on the packaging side of things, but it also
gives folks the ability to remove a specific library without having to
worry about removing others along with it.

On Mon, 2008-01-07 at 11:41 -0500, Scott Kitterman wrote:
> 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:
> 
> http://launchpadlibrarian.net/11178540/buildlog_ubuntu-hardy-i386.mime-tools_5.425-0ubuntu1_FAILEDTOBUILD.txt.gz
> 
> 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 
> significant.
> 
> This problem has been reported for some time:
> 
> https://bugs.launchpad.net/bugs/111800
> https://bugs.launchpad.net/bugs/178536
> 
> 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
>