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

[Aaron Griffin]

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 at archlinux.ca>
Date: Fri, Feb 5, 2010 at 6:18 AM
Subject: Perl packaging guidelines.
To: aaron at 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.