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
