Advice requested; Automatic building of debian packages from CPAN modules

["Jos I. Boumans" <kane@dwim.org>]

Greetings,

I'm the author of CPANPLUS, CPAN.pm's proposed successor. I write you 
to get
some advice on Debian policy and ideas about building and packaging 
perl modules
from CPAN.

Most of you are probably familiar with the C<dh-make-perl> tool that 
can create
a debian package from a CPAN module. This tool has at least 2 known 
shortcomings
at the time of writing:
	* Does not cope with dependencies
	* Does not cope with Module::Build based packages

In an attempt to provide a generic plug-in based system to create 
packages
automatically from CPAN modules (without above mentioned shortcomings), 
we've
now put our efforts on debian packages (after doing PAR, ports and PPM).

While building these .debs we've got very encouraging results, and 
barring
debian policy option tweaks, they're 'technically' sound. However, one 
issue
arises: The debian package system does not allow a file to be 'owned' 
(or
provided) by 2 different packages, which is a problem when updating 
core modules
from CPAN (like for example Test::More and Cwd):

	dpkg: error processing libtest-harness-perl_2.42-1_all.d​eb 
(--install):
	trying to overwrite `/usr/bin/prove', which is also in package perl
	Errors were encountered while processing:
	libtest-harness-perl_2.42-1_all.deb

Now, in 'perl land' it's quite common to have a file be able to come 
from 2
different sources (like perl-core and CPAN), so the question is: what 
does
debian do here?

It seems that debian, when a core modules is updated on CPAN, prefers 
to update
it's own 'core' perl package to include the updated CPAN module. Thus
effectively generating a say, '5.8.4-2', which is the same as the 
original perl
5.8.4 release, with the updated CPAN module in it.

So far, all well and good, but this creates problems when automatically
generating packages that are, or depend on, modules that are dual-lifed 
(ie
exist on CPAN and in the core), as we can not 'just' install the CPAN 
module
on top of what the (debian) core already provided. I can think of a few
possible scenarios:

	* 	The most recent version of the CPAN module has not been integrated
		into the debian perl core. Any module that has a requirement on this
		more recent version will now have unmet dependencies.
	* 	As I only know the environment of my current perl that I am building
		this debian package with (core perl module versions vs CPAN versions
		vs build requirement), I can only guarantee that the package I am
		about to create will work with the version of perl I am currently
		building it with. That effectively means requiring everyone to
		upgrade to at least this version of perl in order to use the
		package. From a 'perl' point of view, there's absolutely no need
		for this, but it might be required for debian.
		Ideally of course, we want the package to depend on the version
		of perl it says it needs, rather than the version of perl it was
		built with.

Any light you can shed on this situation, and the 'best practice' in
debian-land would be much appreciated.

--
	Jos Boumans

	'Real programmers use "cat > a.out"'

	CPANPLUS	http://cpanplus.sf.net