On Tue, Feb 9, 2010 at 3:32 AM, Firmicus <[email protected]> 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
