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

[Dan McGee]

On Tue, Feb 9, 2010 at 12:26 PM, Aaron Griffin <aaronmgriffin at gmail.com> wrote:
> On Tue, Feb 9, 2010 at 3:32 AM, Firmicus <Firmicus at gmx.net> wrote:
>>
>> [Forwarding this from Xyne]
>>
>>>  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.
>>
>>
>> Is the overhead even significant? How expensive are PROVIDES lookups?
>> (Coincidentally, I've thought for a while now that there should be a
>> single PROVIDES list for the local database to avoid opening hundreds
>> of files unnecessarily, even if that is quite fast).
>>
>> What about when distributions change their module roster? This has
>> happened before and will happen again. I see robust dependency
>> resolution as an "obvious advantage". If any important modules ever get
>> moved around (e.g. subsumed into the base distribution from a popular
>> module), then all packages which depend on that module would need to
>> update their depends array.
>>
>> The fact that META.yml files for distributions on CPAN specify modules
>> and not distributions shows that the dependencies are actually the
>> modules themselves. Ignoring upstream convention and Pacman's built-in
>> capabilities to shave a little bit of time off of a PROVIDES lookup
>> doesn't right to me, especially when you factor in the potential
>> dependency breakage, however unlikely that is to affect large
>> distributions.
>>
>>
>>>  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).
>>
>> I've looked at perl-cpanplus-dist-arch while rewriting the pacpan
>> backend. I found the entire CPANPLUS backend to be overkill for
>> creating Pacman packages. Pacpan uses the same files and gets the same
>> results, but without the CPAN shell and other bells and whistles that
>> have no significance for Pacman packaging.
>>
>> That said, if there are particular features that
>> perl-cpanplus-dist-arch has that pacman lacks, let me know which and I
>> will consider adding them. If that project does show itself to be
>> superior for Pacman packaging then I probably switch the backend over
>> to it, but so far the current backend works as expected and is fairly
>> simple with no external dependencies.
>>
>>
>>
>>
>> Two follow-up questions:
>> Do you at least support the idea of renaming CPAN packages with
>> non-standard names to their standard names?
>>
>> If not, what about including the standard name in the provides array?
>>
>> If pacpan didn't include the individual modules in the arrays but
>> instead mapped then all to their distribution, how would you see the
>> matter then?
>
> I have to say that I'm not really up to speed on the perl module
> stuff, but I can see the benefit of adding the actual CPAN name into
> the provides array. I have wasted time in the past looking for some
> "Random::FooBar" type module, only to find that it's in perl-libfoobar
> or something silly

provides are searched by -Ss as well, so I also agree here.

-Dan