Message below is trimmed, but the summary is: pacpan (CPAN wrapper for pacman packages) has been updated with gusto. There is a request to include using pacpan as part of the official guidelines for packaging perl apps for Arch. I think this is a good idea, but it leaves me wondering what we should do with the tool itself - should we be hosting it in the git repos? What do you guys think? ---------- Forwarded message ---------- From: Xyne <xyne@archlinux.ca> Date: Fri, Feb 5, 2010 at 6:18 AM Subject: Perl packaging guidelines. To: aaron@archlinux.org Hi Aaron, You're probably at least vaguely aware of a tool that I wrote a while ago named pacpan, which can autogenerate PKGBUILDs for CPAN packages. In the past worked well enough in most cases but there was room for improvement and I finally found the time to rewrite it recently. It is now a very useful tool for packaging CPAN distributions. I don't want to bore you with the details but it now does the following: *) correctly maps all modules to their distributions *) maps distributions to unique pacman pkgnames which follow the guidelines *) detects depends, makedepends, optdepends, and provides *) can detect missing provides for installed packages *) can update the local database provides while waiting for the packager to update it The provides are actually really important because many official packages do not list the packages that they provide and/or deviate from the standard naming conventions and this causes problems when trying to install other CPAN packages. Patching the local database works but it's an ugly hack. I've posted a thread on the forum to discuss changing the perl packaging guidelines to officially recommend using pacpan as a starting point for all CPAN packages. In most cases the PKGBUILD it generates should work out of the box. In those when it doesn't, it will still provide a comprehensive provides array and contain the correct name. This will improve the CPAN packaging situation by enabling full dependency resolution and by preventing conflicts from people effectively packaging the same packaging under different names and omitting the provides of those packages. ...snip... If I get some sort of official approval for this proposal, I will update the Perl packaging guidelines page in the wiki and begin to open tickets on the bug tracker to update/fix current CPAN packages which are incorrectly named and/or lack complete provides arrays.