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

[Paul Mattal]

On 02/06/2010 10:29 AM, Allan McRae wrote:
> On 06/02/10 09: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?
>>
>
> I'm not sure about the idea.
>
>  From what I understand, Perl comes in CPAN "distributions", which
> contain some modules. We take a "distribution" and make a package. This
> script fills out a provides array with all modules that are part of the
> package and makes the dependencies be these modules. That may be
> technically more correct, but the sacrifice is a lot of complexity that
> I am not sure is really needed.
>
> How often do modules swap from one "distribution" to another? Robustness
> to that is the only advantage I see here. I might be missing something...
>
> Saying that, in total perl modules on my system are what is needed for
> SDL_perl (yay frozen bubble!) and that is the limit of the perl
> packaging I have to deal with.

Where the rubber hits the road on these issues is packaging software 
that requires perl modules. Most that I've encountered require 
particular versions (or greater) of particular perl modules.

It's then the job of the perl-module-dependent packager to try to figure 
out what version of perl incorporated that module. Then as perl 
incorporates more modules into the main distribution, all the 
perl-dependent packages must be changed/updated. There are a lot of 
packages with perl module dependencies.

As at least one step, it seems a good idea for perl to fully list the 
component module provides for what it includes in the distribution. This 
is would seemingly benefit packagers of perl-module-dependent packages 
greatly, and it doesn't add complexity over what we currently have (a 
partial such set of provides).

As for the rest of the proposal, it's less clear to me the right path. 
Perhaps others will have experience to share here.

- P