Item13263: [Discussion] new strategy for the perl dependencies with the automatic debian package builder

new strategy for the perl dependencies with the automatic debian package builder

We have several debian package with missing dependencies.

At this, point, a deb package seems to be build from the DEPENDENCIES found in foswiki directories by a simple name translation (need deeper investigation).

We have other manner to do this :

• using search inside the debian package description (apt-cache search XXX::YYY), but some time it doesn't work (anyone have an example ?)
• simple using perl-depends on source code (is it the manner to build package at this time ?)
• using dh-make-perl package
• using kind of distromatch (seems to be unmaintained)
• other ?

---

I have been wondering about better handling of packages albeit from a different perspective. I've been building my VM via vagrant and for now using a shell script to apt-get install the module or when this fails resort to CPAN. Most perl modules are available but there are exceptions.

The VM is designed to be a git based pseudo-install, although I also intend to build our test and production environments around that.

I was thinking that all we need is perl modules that provides a look-up of the perl module name e.g. Algorithm::Diff to the distribution package name.

my %distro_package = (
    'Algorithm::Diff' => { debian => 'libalgorithm-diff-perl', rpm => 'perl-Algorithm-Diff' },
    'Apache::Htpasswd' => { debian => 'libapache-htpasswd', rpm => 'perl-Apache-Htpasswd' },
);

You should also take advantage of Module::Corelist to identify standard perl modules in the target version of perl you are after. It is itself standard perl.

To create a working †developer VM on Ubuntu 14.04, I needed 33 additional modules via apt-get and 7 more where I had to resort to CPAN.

Those numbers are small and therefore we have a good chance of providing a database of what FW needs to know. The tools above are trying to cover everything. If one of them is mature and complete enough then it's reasonable to use it — OTOH it's another dependency for the project. So far, I get the impression that they are not mature anyway.

†Some extra modules are required for a developer based set-up, e.g. to support the test suite

The test suite comes with the UnitTestContrib and other developer tools with BuildContrib; both of which should list their dependencies. Do we stick with a central database for now or extend each extension DEPENDENCIES file (or directory?) to list distribution package names.

There are pros and cons of either approach. I like the idea of a central database to start with and extend if the need arises.

I'd like at first to check the dependencies files of all the extensions in the Foswiki git repo; and extract a list of all the unique CPAN modules required (broken down by core and non-core perl). That would give us an idea of the size of the database to maintain.

-- JulianLevens - 19 Feb 2015

It seems as though there must be some available resource to map CPAN module names to their rpm / deb / ebuild equivalent. Most of these are formula based, however there are exceptions.

• http://deb.perl.it/debian/cpan-deb/

This perlmaven page has details for a number of distributions.

Even though the tool has some issues, see https://github.com/foswiki/distro/blob/master/core/tools/dependencies_installer.pl It has a lot of the conversions already identified.

-- GeorgeClark - 19 Feb 2015

Commenting is disabled while not logged in