Forwarding. Removed a small chunk of text asking me to forward this on :) ---------- Forwarded message ---------- From: Xyne <xyne@archlinux.ca> Date: Wed, Feb 24, 2010 at 9:02 PM Subject: Re: Perl packaging guidelines. To: Aaron Griffin <aaronmgriffin@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 packages. 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: perl-extutils-parsexs>=2.220.200 perl-module-build>=0.360.300 The perl package in [core] provides perl-extutils-parsexs=2.200.200 perl-module-build=0.340.201 and the following are available on CPAN as independent distributions perl-extutils-parsexs=2.220.300 perl-module-build=0.360.300 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 this. 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.