[arch-dev-public] Fwd: Re: Fwd: Perl packaging guidelines.
dpmcgee at gmail.com
Tue Feb 9 13:34:48 EST 2010
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
>>> 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.
More information about the arch-dev-public