[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