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

Firmicus Firmicus at gmx.net
Sun Feb 7 16:47:51 EST 2010


On 06/02/2010 00:28, Aaron Griffin wrote:
> 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?
>
>    

This is an area where I have a pretty solid experience, as as perl dev, 
arch user, and maintainer of several perl packages in extra and 
community. I tend to agree with Allan here. We should only package and 
take into consideration what on CPAN is called a distribution, i.e. a 
tarball containing a bunch or related perl modules. The mapping between 
modules and distributions is available in a plain text database on each 
CPAN mirror, and can be figured out by the common tools used to install 
cpan stuff from the command-line (cpan and cpanp). I think it is quite a 
BAD idea to put all module names in the provides array, as this can 
easily yield hundreds of elements without obvious advantage I can think 
of. Our poor lil Pacman has better things to do than take that overload 
into account.

That said, I do acknowledge Xyne's effort! I have written a very similar 
tool years ago, which is still available in AUR (perl-cpanplus-pacman), 
but for which I have alas not dedicated as much effort and commitment as 
Xyne did with pacpan. My own approach has however inspired another 
project, called perl-cpanplus-dist-arch (also in AUR), which IMHO is 
superior to both my own cpan4pacman and Xyne's pacpan. (That said I 
still use cpan4pacman (together with a few helper shell scripts and the 
devtools) to maintain my own local repository of 550 CPAN packages, all 
of which I keep uptodate with relative ease).

So -1 from me: the added complexity this proposal would bring clearly 
outweighs its advantages!

But OTOH I am fine with the idea of hosting pacpan on git, it is a good 
tool. I just don't want the policy it adheres to become our official one.

F




More information about the arch-dev-public mailing list