[arch-dev-public] Fwd: Re: Fwd: Perl packaging guidelines.

Aaron Griffin aaronmgriffin at gmail.com
Thu Feb 25 15:45:37 EST 2010

Forwarding. Removed a small chunk of text asking me to forward this on :)

---------- Forwarded message ----------
From: Xyne <xyne at archlinux.ca>
Date: Wed, Feb 24, 2010 at 9:02 PM
Subject: Re: Perl packaging guidelines.
To: Aaron Griffin <aaronmgriffin at gmail.com>

Hi Aaron,

I just came across a clear example of the advantage of specifically
listing the modules and their versions in the provides array of CPAN

The perl package in core provides several modules which are also
available as independent modules on CPAN. The modules provided by
the Perl package are older and presumably stable versions whereas the
independent modules are newer and maybe experimental.

(Note that in many of these cases the module _is_ the distribution as
there is only one module.)

Several distributions require specific versions of those modules and it
therefore makes sense for the perl package to specify exactly which
modules it provides, including their versions.

Here's a concrete example that came up when trying to build Padre,
which has a big dependency tree (80 distributions|packages):

At some point in the build process, the following are required:

The perl package in [core] provides

and the following are available on CPAN as independent distributions

Without the complete provides array any package which depends on
perl-module-build would have to keep track of which version is provided
by the perl package in [core] and manually update the depends array
whenever the required version or the provided version changed (with
all the waste that entails). With the complete provides array, this can
be handled automatically by pacman using features that were designed for

I think it would be worth discussing this with the Arch Haskell team as
well, as they have also realized the advantages of full provides
arrays. Admittedly they are longer for CPAN distributions, but they
are not more complex programmatically.

More information about the arch-dev-public mailing list